From: Gil B. <co...@ba...> - 2005-10-29 09:19:00
|
One tiny important detail left out :) According to information on the net (http://patchwork.ozlabs.org/linuxppc/patch?id=3D1268) the precise = regression moment was between 2.6.10-rc1-bk3 and 2.6.10-rc1-bk8. I have it confirmed between 2.6.8 and 2.6.13.4 myself. -----Original Message----- From: ge...@so... [mailto:ge...@so...] On Behalf Of Geert Uytterhoeven Sent: Friday, October 28, 2005 10:19 PM To: lin...@li... Subject: Re: [Linux-fbdev-users] atyfb: brokenness on PowerMac 5500 and Beige G3 On Fri, 28 Oct 2005, coutal coutal wrote: > i am using the atyfb driver on my powermac 5500 (ati rage II 215GT). = after > upgrading the kernel, three vertical bands of visible distortion = appeared in > my console. they are not videomode-tied (tried almost all my card supports) > and thus i suspect some breakage in the driver. Which kernel version worked fine? Which one caused the regression? > can anyone please have a look at it? > moreover, what could cause such an effect? would it be memory clock or = pll > programming? please enlighten me a bit, i am curious. This looks more like a problem with the display FIFO programming (DSP_* registers): some RAGE chips have 24 entries in the display FIFO, others = have 32. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. = But when I'm talking to journalists I just say "programmer" or something = like that. -- Linus Torvalds |
From: Gil B. <co...@ba...> - 2005-10-31 07:05:52
|
Hello, =20 I suspect I have found the reason for the breakage I reported earlier in = the driver - but I'd be very happy if someone was confirming that my attempt wouldn't mess up my hardware before I set off to test it. =20 This addition: =20 + /* according to ATI, we should use clock 3 for acelerated mode */ + par->clk_wr_offset =3D 3; =20 comes up right after a nice piece of code that actually tries to mask clk_wr_offset: =20 + if (!(aty_ld_le32(CRTC_GEN_CNTL, par) & CRTC_EXT_DISP_EN)) + par->clk_wr_offset =3D (inb(R_GENMO) & 0x0CU) >> 2; + else + par->clk_wr_offset =3D aty_ld_8(CLOCK_CNTL, par) & 0x03U; =20 and so makes this code redundant with a static value that "seems" to = come out of nowhere. Furthermore, looking at atyfb.h, this particular register has overloaded meaning (by its comment) so it may cause the unexpected results I'm = seeing. But. these 4 lines of code replace an even bigger PLL calculation = routine, and I do not know if they are correct or are just an attempt to read the value that got "commented out" because it was not complete. =20 So I ripped out the first two lines and count on the next 4 lines to initialize clk_wr_offset. I already compiled the appropriate kernel, but since my understanding of = all the hidden subtleties of the mach64 registers is far from complete, and = my only mac is an all-in-one machine where damage to the crt by wrong = clocking will render the entire box useless, I would appreciate it if you tell me = at least what you think and if I am putting my hardware at any risk. =20 Thanks, =20 Gil Bahat, System Administrator. |
From: Ville <sy...@sc...> - 2005-11-01 00:06:01
|
On Mon, Oct 31, 2005 at 09:07:32AM +0200, Gil Bahat wrote: > Hello, >=20 > =20 >=20 > I suspect I have found the reason for the breakage I reported earlier i= n the > driver - but I'd be very happy if someone was confirming that my attemp= t > wouldn't mess up my hardware before I set off to test it. >=20 > =20 >=20 > This addition: >=20 > =20 >=20 > + /* according to ATI, we should use clock 3 for acelerated mode */ > + par->clk_wr_offset =3D 3; >=20 > =20 >=20 > comes up right after a nice piece of code that actually tries to mask > clk_wr_offset: >=20 > =20 >=20 > + if (!(aty_ld_le32(CRTC_GEN_CNTL, par) & CRTC_EXT_DISP_EN)) > + par->clk_wr_offset =3D (inb(R_GENMO) & 0x0CU) >> 2; > + else > + par->clk_wr_offset =3D aty_ld_8(CLOCK_CNTL, par) & 0x03U; >=20 > =20 >=20 > and so makes this code redundant with a static value that "seems" to co= me > out of nowhere. clk_wr_offset just decides which VCLK "preset slot" we use to store the=20 VCLK settings. It won't make any real difference which one is used. It's=20 just some standard to use the last slot. I guess the lower slots are=20 typically used for storing VGA clock settings or something like that. > Furthermore, looking at atyfb.h, this particular register has overloade= d > meaning (by its comment) so it may cause the unexpected results I'm see= ing. I think that just means that it's used with GX chips as an actual write offset. With CT chips it's used as a clock id which is actaully the same thing as the preset slot thin I said earlier. In other words it has=20 nothing to do with your case. Did you try the dsp_loop_latency patch I sent earlier? --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |
From: Gil B. <co...@ba...> - 2005-11-03 10:19:13
|
Sorry for the late reply, But i've been getting a lot of internal = compiler errors on my powermac and it's slow to compile kernels on. Only when I = found out it was due to not enabling swap space, did compiling go smoother. = While it did seem to be able to completely compile both patches, neither of = them worked - the phenomena is still there and the kernel crashes almost = right after loading the aty framebuffer.=20 Maybe some testing with a more stable box is in order... but that's all = I have. I'll continue looking.=20 Thanks, Gil Bahat |
From: Gil B. <co...@ba...> - 2005-11-05 17:14:55
|
Hello, I have now decoded and mapped the register differences as they appeared in http://patchwork.ozlabs.org/linuxppc/patch?id=1268. However, I have went through the code path and cannot explain most of the reasons for the changes, nor can I estimate their effect. That's where the list might come handy :) So, after applying the patch: BUS_CNTL changes from 7b23a040 to 7b23a050. this is due to the code section that enables auxillary aperture to enable access to 8mb memory cards. CRTC_GEN_CNTL changes from 03000200 to 0b000200. I have noticed the code in mach64_ct.c has removed a particular bit masking when assigning GEN_CNTL, but I have no idea why. DSP_CONFIG also changes. It becomes 004805FA instead of 004808e2. no idea why - the code that generates it looks the same to me. DSP_ON_OFF also changes. It becomes 00B4043B instead of 009C0666. ditto for the reasoning. PLL is also different in its first 24 bytes: ADD52414 instead of ADD52144 A80382D1 instead of E80382D1 8E829601 instead of 8E9E9814 I don't know how to decode this yet. Can anyone have a look at mach64_ct.c and maybe notice what I haven't noticed regarding the DSP programming? Thanks, Gil Bahat, System Administrator. |
From: Gil B. <co...@ba...> - 2005-11-07 08:23:53
|
Okay, I made some very important progress: I hard-coded the correct values into dsp_config and dsp_on_off. Presto - = no more disruption. But the code does seem to boot when using quik. Which means that when OF initializes the card, it sets some values that are not being touched = later on, or at least used to generate the (bogus) dsp_config and dsp_on_off. Since the BIOS probe code entered, maybe the driver was cleaned of = forced programming of registers, which macs depended on for correct operation. Gil Bahat, System Administrator. -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of Gil Bahat Sent: Saturday, November 05, 2005 7:15 PM To: lin...@li... Subject: RE: [Linux-fbdev-users] atyfb: brokenness on PowerMac 5500 and Beige G3 Hello, I have now decoded and mapped the register differences as they appeared = in http://patchwork.ozlabs.org/linuxppc/patch?id=3D1268. However, I have = went through the code path and cannot explain most of the reasons for the changes, nor can I estimate their effect. That's where the list might = come handy :) So, after applying the patch: BUS_CNTL changes from 7b23a040 to 7b23a050. this is due to the code = section that enables auxillary aperture to enable access to 8mb memory cards. CRTC_GEN_CNTL changes from 03000200 to 0b000200. I have noticed the code = in mach64_ct.c has removed a particular bit masking when assigning = GEN_CNTL, but I have no idea why. DSP_CONFIG also changes. It becomes 004805FA instead of 004808e2. no = idea why - the code that generates it looks the same to me. DSP_ON_OFF also changes. It becomes 00B4043B instead of 009C0666. ditto = for the reasoning. PLL is also different in its first 24 bytes: ADD52414 instead of ADD52144 A80382D1 instead of E80382D1 8E829601 instead of 8E9E9814 I don't know how to decode this yet. Can anyone have a look at mach64_ct.c and maybe notice what I haven't noticed regarding the DSP programming? Thanks, Gil Bahat, System Administrator. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. = Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Linux-fbdev-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users |