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

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.

My card's behaviour isn't just the best yet: it looks like the monitor is out 
of sync, and I can't get any acceptable mode (I've tryied a lot of modes with 
fbset). Reading characters from the terminal is impossible.

However, I could successfully run 'dfbsee image.png', and the image was shown 
nicely on the display. Maybe DirectFB is performing another video mode 
switch..?

Anyway, I'm attaching the patch, which fixes the oops'es I was getting 
previously. I'll try to understand what's going wrong with video modes here, 
and if I came to a solution I'll post it. Any help is welcome, of course :-)

Thanks,
Lucas