[PATCH] Radeon driver fixes #4

[obiwan at mailmij.org]

I tried Ben's patch so I might as well comment a bit upon it. For replies
please CC me as I'm not subscribed.

> - Fix various bugs in RADEONProbePLLParameters() and made it overall
> more robust. I'm now probing my PLL parameters on my 3 test machines
> 100% of the time properly. This might fix issues with bandwidth
> calculation

For me (snowwhite ibook 2.2), its not so robust, but it still works:) I
noticed that the kernel radeonfb driver disables interrupts when
determining xtal. I think X can't do this and as a result the xtal ends up
much lower on my machine. It defaults then to 27 MHz, which is ok for my
M7, but couldn't the tollerance be increased (check if it is higher than
26.5 instead of 26.9)? Otherwise, there are perhaps ways to get more
realtime performance on linux?

Secondly, mclk and sclk are set to 90 Mhz, while the kernel says they are
at 180 Mhz. Both values seem to work, even 200 mhz works, but is this
correct?

Lastly, ValidateFPModes is only called when ddcmodes <=1. Why is this?

For me, the edid on my panel is a bit sparse in info. It says it supports
only 1 vesa mode (1024x768 at 60) and 1 manufacturer mode (which is almost
identical to the vesa mode). It also doesn't give any supported
frequency range. So I have 2 1024x768 modes available but no others, and
with 2 ValidateFPModes is never called. I'm not sure why it is called when
you only have 1 ddcmode, is it common for panels to put only the best mode
in EDID because the RMX can scale this mode?

My card is perfectly capable of scaling the screen to all vesamodes. I
tried to copy the part of RADEONValidateFPmodes (where it adds all smaller
vesa modes) into ValidateDCCModes, and can now use xrandr to rescale my
display. Would there be a problem if ValidateDCCModes was patched to allow
this? Or just to always call ValidateFPModes with a panel?


d.