On Saturday 11 December 2004 19:37, Ville Syrjälä wrote:

On Sat, Dec 11, 2004 at 02:51:42PM -0200, Lucas Correia Villa Real wrote:

quoted

On Friday 10 December 2004 19:19, Antonino A. Daplas wrote:

quoted

On Saturday 11 December 2004 04:44, Lucas Correia Villa Real wrote:

quoted

Hi,

I'm trying to use atyfb on 2.6.10-rc3, but I'm getting a kernel oops
just at modprobe time. By tracking the problem, it seems that
'pll_limits.xclk' is the heart of the problem, as seen in line 2210
from atyfb_base.c:

par->xclk_per = 1000000/par->pll_limits.xclk;

It happens that pll_limits.xclk is zero, because of an attribution
made on line 3246:

par->pll_limits.xclk = pll_block.XCLK_max_freq/100;

pll_block.XCLK_max_freq, in this case, is read from BIOS a few lines
above (at line 3229, to be more precise), and the value being
returned from this copy here is 20. So we have a problem, since the
result from 20/100 = 0 will be used as denominator to set
par->xclk_per's value.

Buggy BIOS?  Why not skip the init_from_bios() step, since xclk will be
initialized in the function correct_chipset(), just a few lines above?

If that works, perhaps a boot option can be added such as no_bios?

Hi,

When trying to skip the initialization from bios the driver gets crazy:

atyfb: using auxiliary register aperture
atyfb: 3D RAGE II+ (Mach64 GTB) [0x4755 rev 0x9a]
atyfb: 512K RESV, 14.31818 MHz XTAL, 200 MHz PLL, 67 Mhz MCLK, 67 MHz
XCLK atyfb: Unsupported xclk source:  5.
atyfb: vclk out of range
atyfb: not enough video RAM
atyfb: not enough video RAM
atyfb: not enough video RAM
...
atyfb: vclk out of range
atyfb: can't set default video mode
...

After this broken initialization, if I try to rmmod atyfb, the kernel
oops'es. So, I've decided to keep doing the initialization from bios, but
if the bios is told to be buggy, correct_from_chipset() is called again
to fix some stuff informed by the bios.

Are you saying you don't get these warnings if you call init_from_bios()?
That sounds really strange as the only thing init_from_bios() does is get
the PLL limits. So if you call correct_chipset() after init_from_bios() it
should behave exactly the same as if you didn't call init_from_bios() in
the first place.

I've done some more tests, and I discovered that I was being fooled by X. When 
I try to load the atyfb module after X has been started and finished, the 
module is loaded successfully -- given that the init_from_bios() function is 
skipped.

So you were right, there's no need to call correct_chipset() again. I just 
guess X is setting some hardware registers that atyfb is missing. I'll give a 
look on Xorg drivers tomorrow to see if something "appears" magically to my 
eyes.

I've fixed the previous patch, sent in attach. It now also uses "use_bios" 
instead of the "broken_bios" parameter.

By the way, are datasheets to ATI Rage II+ freely available? Maybe I can 
provide some better feedback by trying to check things there first.

Thanks!
Lucas