Radeon 9000 Pro corruption problem on PPC when DRI is enabled

[Benjamin Herrenschmidt]

> > (II) RADEON(0): PLL parameters: rf=0 rd=12 min=0 max=2097152; xclk=0

> These parameters look very bogus. Either your video bios has simply
> screwed up values there or the driver fails to read it correctly (for
> instance different encoding than assumed).

If it's a "mac" card, it has no x86 BIOS with the expected tables in it.
radeonfb can get some of the values from the Open Firmware, X doesn't
know how to do that. However, X should detect that case and fallback to
"measuring" the values from the card. It looks like that didn't happen
which I find a bit strange. Worth looking at what's going on in the
code. If it's not a "mac" card (an x86 card in Pegasos machine for
example), then I don't know for sure, reading the ROM should have
worked.

so RADEONGetClockInfoFromBIOS() should have returned FALSE and for some
reason didn't. I suspect we aren't doing a necessary sanity check on the
ROM image before reading things from it (not even checking it's actually
an ATI x86 BIOS ROM image). We should add that (radeonfb does some basic
checkings like that too, at least checks it's an x86 BIOS ROM image). We
should also add some sanity checking of the values read from the ROM.

I'm in a hurry at the moment and thus can't produce a patch, so feel
free to beat me to it there. If not, I'll have a look later this week.

Ben.

> > +(**) RADEON(0): Programming CRTC1, offset: 0x00000000 +(**)
> > RADEON(0): Wrote: 0x0000000c 0x00000000 0x00000000 (0x0000bc00) +(**)
> > RADEON(0): Wrote: rd=12, fd=0, pd=0 +(WW) RADEON(0): You may not have
> > enough display bandwidth for current mode +If you have flickering
> > problem, try to lower resolution, refresh rate, or color depth
> The warning I believe is because of the wrongly read values above, so
> the calculation is just plain wrong. With 128bit DDR ram (even at an 
> unknown frequency, it can't be THAT slow) you have more display 
> bandwidth than you'd ever need for any resolution at any bit depth at 
> any refresh rate.
> 
> > I don't see anything that looks problematic. There's a warning about 
> > display bandwidth and flickering, but I'm not experiencing any 
> > flickering...
> > 
> > Yet I still get a blank screen.
> Those wrong values could lead to incorrectly calculated pll parameters 
> maybe, that's a part of the driver I know nothing about. Someone else 
> would need to answer that.
> 
> > I did notice however, that it took my
> > monitor longer to decide whether it was getting a signal or not on
> > lower resolutions. This thing's light is normally green when in
> > normal operation and turns orange when sleeping or not getting a
> > signal. On resolutions above 832x624, the light turns orange
> > immediately after starting X. With resolutions equal to or below
> > that, it took a few extra seconds to turn orange. This could very
> > well have just as much to do with the price of tea in China as my
> > corrupted screen, however... I don't know :-/.
> It could be related, if the monitor is somewhat strict about what 
> modelines it accepts try to find another one from someone which has the 
> same monitor. If the parameters though as I almost suspect are really 
> calculated wrong that won't help.
> 
> Roland
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg