From: Lucas Correia Villa Real <hidden> Date: 2004-12-10 20:44:10
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.
Since I didn't know what clock was being expected by the driver, I couldn't go
any longer. If some of you has time and can give a look on it, I'm sending
some information about my card, as well as ksymoops results and .config.
Thanks,
Lucas
02:0d.0 VGA compatible controller: ATI Technologies Inc 3D Rage II+ 215GTB
[Mach64 GTB] (rev 9a) (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB]
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: 0 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 5
Region 0: Memory at ec000000 (32-bit, non-prefetchable) [size=16M]
Region 1: I/O ports at b800 [size=256]
Region 2: Memory at eb800000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at ee7c0000 [disabled] [size=128K]
From: Antonino A. Daplas <hidden> Date: 2004-12-10 21:19:33
On Saturday 11 December 2004 04:44, Lucas Correia Villa Real wrote:
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?
Tony
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
From: Lucas Correia Villa Real <hidden> Date: 2004-12-11 16:51:40
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
From: Ville Syrjälä <syrjala@sci.fi> Date: 2004-12-11 21:37:59
On Sat, Dec 11, 2004 at 02:51:42PM -0200, Lucas Correia Villa Real wrote:
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.
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
From: Lucas Correia Villa Real <hidden> Date: 2004-12-13 03:30:42
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