[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