[Xorg-driver-geode] cim_vg modification needed

[Mart Raudsepp]

> Hello,

Hello,

> I have attempting to port a system my company develops to Fedora for quite
> some time and have always been stuck on getting the geode video driver
> working properly (the VESA driver has always worked for me though).  So
> recently we updated the WinXP graphics driver on this same system and it
> produced the same problem that xorg-amd*/xorg-geode* have always given me
> where the colors were just not displayed properly and has a fuzzy
> appearance on the panel.  So after a few months of debugging the XP
> driver, AMD discovered that our system doesn't like the default value
> written to the PAD_SELECT_REGISTER when the driver is setting the panel
> timings.  Their solution was to read the values first and OR them with the
> default values.  So I made this change to 2.10.0 and it worked like a
> charm (with a custom xorg.conf).
>
> I have attached the modified cim_vg.c file that I modified in 2.10.0 which
> works on my system, but I'm wondering how safe this change is and also if
> this is could be a sign of other problems.

Possibly, but the driver overwriting the value completely sounds potential
trouble. Could you check what the register value is after BIOS (before
geode xorg driver gets to touch it), so we can see which of the bits
actually matter here?

> We are using General Soft.
> BIOS on our LX800/CS5535.

I don't suppose you could check if it's setting anything for MSR_PADSEL
(0x48002011)?

> I couldn't find much information on the pad
> select register, so any thoughts or suggestions would be greatly
> appreciated.

I didn't find anything besides LX databooks MSR_PADSEL documentation
either, whose most bit descriptions weren't exactly descriptful beyond
names indeed. Though some of the names are somewhat self-descriptive it
seems.

Note that the lxfb kernel framebuffer driver appears to do exactly the
same thing - hard set to 0000003F:DFFFFFFFh overwriting anything
previously there. So it'd be interesting to know which bit(s) enable is
missing for your board.
I put my bets on bit 39 (VOPCINV) because everything else non-reserved is
already set high and you are OR'ing your stuff on top of it.
The documentation says (from the LX databook that is completely freely
available):

VOPCINV - Invert VOP Clock.
This is used to invert the VOP output clock.
This may be used to meet system timing requirements.
        0: Non-inverted.
        1: Inverted.



Regards,
Mart Raudsepp
Artec Design LLC