Radeon 9000 Pro corruption problem on PPC when DRI is enabled

[Ari Entlich]

On Mon, 2006-08-21 at 09:20 +1000, Benjamin Herrenschmidt wrote:
> > > (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).
> 

Here's something PLL-related from a 6.8.2 logfile I have kicking around:

(WW) RADEON(0): Video BIOS not detected, using default clock settings!
(II) RADEON(0): Probed PLL values: xtal: 27.000000 Mhz, sclk: 274.500000 Mhz, mclk: 249.750000 Mhz

Hmm...

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

I'm actually not sure if it's a mac card or not. This isn't a Pegasos
machine though, that's for sure (see the original message).

Here's what lspci -vv says:

00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01) (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc Radeon RV250 If [Radeon 9000]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 255 (2000ns min), Cache Line Size 08
        Interrupt: pin A routed to IRQ 48
        Region 0: Memory at 98000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at f0000400 [size=256]
        Region 2: Memory at 90000000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at f1000000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
                Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=<none>
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

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

I could /try/ to look at the code, but I know nothing about Radeon
hardware and my C skills aren't quite professional-grade just yet, so I
can't promise anything :-).

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

I don't think it is strict about modelines. I've done a lot of messing
with xvidtune, and that hasn't caused the monitor to just black out or
develop any problems. Also, that config I posted isn't actually the one
I use for everyday stuff, I just posted it because it's sufficiently
minimal that people wouldn't start saying "oh, turn this off, it should
help". The corruption problem happens with that config and my normal
config, anyway, so it shouldn't matter. With my normal config I have a
modeline which makes the monitor work correctly at 1152x864 at 75Hz
refresh (it uses some non-standard timings). The problem appears with
that modeline also. I've also tried various other resolutions with no
modeline at all, to no avail. Here's the other modeline:

Modeline "1152x864" 100.000 1152 1196 1324 1464  864 869 872 908  +HSync +VSync

However, above all, I don't want to get sidetracked off of my original
complaint. I would much rather have an un-corrupted screen (see original
message for links to pictures) with UseFBDev true (even if it is ugly
and unnecessary) than a corrupted screen with UseFBDev false.

Thanks,
 Ari