[Openchrome-devel] xf86-video-openchrome: 2 commits - configure.ac src/via_tmds.c
Luc Verhaegen
libv at skynet.be
Fri Feb 24 04:57:49 UTC 2017
On Fri, Feb 24, 2017 at 04:00:58AM +0000, Kevin Brace wrote:
> configure.ac | 2 -
> src/via_tmds.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 70 insertions(+), 1 deletion(-)
>
> New commits:
> commit 9a27dc4f9aab50d7c792f8c7a4acaa28a2e43acd
> Author: Kevin Brace <kevinbrace at gmx.com>
> Date: Thu Feb 23 19:59:29 2017 -0800
>
> Version bumped to 0.5.184
>
> This version fixes FIC CE260 / CE261 netbook integrated TMDS interface
> (DVI) on / off. This fix also aids CX700 or later chipsets that have
> the proper strapping resistor values set for DVI use. Another major bug
> fix for OpenChrome DDX.
>
> Signed-off-by: Kevin Brace <kevinbrace at gmx.com>
>
> diff --git a/configure.ac b/configure.ac
> index 8efe157..728cc52 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -23,7 +23,7 @@
> # Initialize Autoconf
> AC_PREREQ(2.57)
> AC_INIT([xf86-video-openchrome],
> - [0.5.183],
> + [0.5.184],
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/openchrome],
> [xf86-video-openchrome])
>
> commit 1bfe1ad714051b6acc7fbc0af715371aa47f2d2b
> Author: Kevin Brace <kevinbrace at gmx.com>
> Date: Thu Feb 23 19:54:49 2017 -0800
>
> Improvement in initializing integrated TMDS (DVI)
>
> Had to add a special handling case in order to properly handle FIC CE260 /
> CE261 netbook integrated TMDS interface (DVI) turn on / off. This fix aids
> reinitialization when resuming from standby. FIC CE260 / CE261 were sold as
> Everex CloudBook and Sylvania g netbook. This fix also aids CX700 or later
> chipsets that have the proper strapping resistor values set for DVI use.
>
> Signed-off-by: Kevin Brace <kevinbrace at gmx.com>
>
> diff --git a/src/via_tmds.c b/src/via_tmds.c
> index 21b6cac..5a89561 100644
> --- a/src/via_tmds.c
> +++ b/src/via_tmds.c
> @@ -278,6 +278,73 @@ viaTMDSPower(ScrnInfoPtr pScrn, Bool powerState)
> "Exiting viaTMDSPower.\n"));
> }
>
> +static void
> +viaTMDSIOPadSetting(ScrnInfoPtr pScrn, Bool ioPadOn)
> +{
> + vgaHWPtr hwp = VGAHWPTR(pScrn);
> + VIAPtr pVia = VIAPTR(pScrn);
> + CARD8 sr12, sr13, sr5a;
> +
> + DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "Entered viaTMDSIOPadSetting.\n"));
> +
> + if ((pVia->Chipset == VIA_CX700)
> + || (pVia->Chipset == VIA_VX800)
> + || (pVia->Chipset == VIA_VX855)
> + || (pVia->Chipset == VIA_VX900)) {
> +
> + sr5a = hwp->readSeq(hwp, 0x5A);
> + DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "SR5A: 0x%02X\n", sr5a));
> + DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "Setting 3C5.5A[0] to 0.\n"));
> + ViaSeqMask(hwp, 0x5A, sr5a & 0xFE, 0x01);
Please check what ViaSeqMask does.
ViaSeqMask(hwp, 0x5A, 0, 0x01);
would have sufficed. That's why i wrote this thing like that.
> + }
> +
> + sr12 = hwp->readSeq(hwp, 0x12);
> + DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "SR12: 0x%02X\n", sr12));
> + sr13 = hwp->readSeq(hwp, 0x13);
> + DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "SR13: 0x%02X\n", sr13));
> +
> + switch (pVia->Chipset) {
> + case VIA_CX700:
> + case VIA_VX800:
> + case VIA_VX855:
> + case VIA_VX900:
> + /* 3C5.13[7:6] - DVP1D15 and DVP1D14 pin strappings
> + * 00: LVDS1 + LVDS2
> + * 01: DVI + LVDS2
> + * 10: Dual LVDS (LVDS1 + LVDS2 used
> + * simultaneously)
> + * 11: DVI only */
> + if ((((~(sr13 & 0x80)) && (sr13 & 0x40))
> + || ((sr13 & 0x80) && (sr13 & 0x40)))
> + || (pVia->isVIANanoBook)) {
That pci-id based table all of a sudden looks a lot more sane, no?
> + viaLVDS1SetIOPadSetting(pScrn, ioPadOn ? 0x03 : 0x00);
> + }
> +
> + break;
> + default:
> + break;
> + }
> +
> + if ((pVia->Chipset == VIA_CX700)
> + || (pVia->Chipset == VIA_VX800)
> + || (pVia->Chipset == VIA_VX855)
> + || (pVia->Chipset == VIA_VX900)) {
> +
> + hwp->writeSeq(hwp, 0x5A, sr5a);
> + DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "Restoring 3C5.5A[0].\n"));
> + }
> +
> + DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> + "Exiting viaTMDSIOPadSetting.\n"));
> +}
> +
> void
> viaExtTMDSSetDisplaySource(ScrnInfoPtr pScrn, CARD8 displaySource)
> {
> @@ -764,11 +831,13 @@ via_tmds_dpms(xf86OutputPtr output, int mode)
> switch (mode) {
> case DPMSModeOn:
> viaTMDSPower(pScrn, TRUE);
> + viaTMDSIOPadSetting(pScrn, TRUE);
> break;
> case DPMSModeStandby:
> case DPMSModeSuspend:
> case DPMSModeOff:
> viaTMDSPower(pScrn, FALSE);
> + viaTMDSIOPadSetting(pScrn, FALSE);
> break;
> default:
> break;
Do you really think that i made those choices on a whim? Or could it
perhaps be that i had my well though through reasons for them?
Luc Verhaegen.
More information about the Openchrome-devel
mailing list