[Xorg-driver-geode] Geode LX video testing results

[Jordan Crouse]

On 13/12/07 22:07 -0500, Bart Trojanowski wrote:
> * Bart Trojanowski <bart at jukie.net> [071213 17:26]:
> > > What that function tries to do is map the VGA space and 
> > > look for a VGA signature (which won't be there on LinuxBIOS implementations),
> > > and then behaves accordingly.  Apparently its not working on some 
> > > BIOSes, but is working on others, which leads me to believe that this 
> > > might be a memory problem somewhere along the line.
> > 
> > The log is pretty useless when it comes to the freeze case.  I'll try to
> > get you better information as to where the code actually freezes.
> 
> I was getting problem running gdbserver with X.  SIGTRAP errors.
> I said I wasn't an X developer... indeed I am from the kernel world, so
> as a result I am really really good at printk() debugging :)
> 
> So using what I know, I wrote some code to send a TCP log messages with
> TCP_NODELAY and for good measure an fsync() after each message.  Then I
> sprinkled log messages printing the __LINE__ number all over
> LXPreInit().  Barbaric, I know.

printk/printf is the only way to debug - even X developers know that
(and honestly, I'm not a X developer either  - this is low level, _almost_
in the kernel development.  X developers are guys that do things with
GUIs.  I don't do GUIs.. :)).

In the future, ErrorF is your friend.  But yours sounds like a fun hack.

> Anyway, I am using the patched version.  And I didn't put in my
> useVGA=FALSE hack as I wanted it to freeze.
> 
> Running X -configure I get a freeze inside the call to
> 
>         GeodeProbeDDC(pScrni, pEnt->index);

This is on the Thincan?  If so, then I'm confused - I thought the thincan
didn't have a VGA BIOS, and the _only_ way we're getting into that function
is if LXCheckVGA returns TRUE.

But, lets pretend that for as of yet unexplained behavior, somehow the
CheckVGA function is returning true.  So then, we assume that VGA is
there, and we merrily go off and and try to get the DDC information,
which we know will blow up because the Thincan doesn't have the DDC pins
enabled, but rather the second serial port.

This is badness, but there really isn't anything that the driver can do
in this situation - at some point, we have to make certain assumptions.
The assumption that DDC will at least not blow up if VGA is present
is an assumption that I can feel good about.  

DDC may also be blowing up on General Software, but probably for other
reasons then the pins being muxed.

The third option is that we just plain screwed up the DDC function - I'll
compare to Intel and verify.

Jordan