Radeon 9000 Pro corruption problem on PPC when DRI is enabled

[Roland Scheidegger]

Ari Entlich wrote:
>> I'm not sure where the requirements for pitch are exactly coming
>> from (except when you use color tiling, which you can't due to the
>> same UseFBDev option), but maybe alignment is wrong somewhere when
>> you're using the cp accel path instead of mmio (which is what you
>> get without dri). Alex might know more about this. You might try to
>> get rid of that (imho ugly and utterly useless - well the idea is
>> sound the implementation is not because way too limited) UseFBDev
>> option, that might fix things. Maybe you need to specify a 
>> different modeline, I guess there was nothing in the log which
>> indicated anything wrong when UseFBDev was not used?
> 
> Here's a diff between the UseFBDev true and UseFBDev false log files 
> (dri off, bit depth 16):

> (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).

> +(**) 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