* Re: Patch: Make iBook1 work again [not found] <Pine.LNX.4.44.0309162303490.32610-100000@deadlock.et.tudelft.nl> @ 2003-09-17 20:07 ` Benjamin Herrenschmidt 2003-09-17 20:42 ` Daniël Mantione 2003-09-17 21:10 ` Daniël Mantione 0 siblings, 2 replies; 15+ messages in thread From: Benjamin Herrenschmidt @ 2003-09-17 20:07 UTC (permalink / raw) To: Daniël Mantione; +Cc: linux-kernel mailing list, Marcelo Tosatti Unfortunately, the wallstreet doesn't work neither. I get something strange on the screen. It's somewhat sync'ed but divided in 4 vertical stripes, each one displaying the left side of the display (+/- offseted), along with some fuzziness (clock wrong). XFree86 "ati" driver works fine (and manages somewhat to probe the panel type and clocks properly ...) It's an LT-G (0x4c47 rev 0x80), 14.31818 XTAL, 230Mhz PLL, 63Mhz MCLK & XCLK (so far it sounds good), mode properly detected (1024x768-60 from the mac sense values read in nvram) but the display isn't correct. I can do register dumps to compare, though I may not have time until next week. Ben. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-17 20:07 ` Patch: Make iBook1 work again Benjamin Herrenschmidt @ 2003-09-17 20:42 ` Daniël Mantione 2003-09-17 21:12 ` Benjamin Herrenschmidt 2003-09-17 21:10 ` Daniël Mantione 1 sibling, 1 reply; 15+ messages in thread From: Daniël Mantione @ 2003-09-17 20:42 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linux-kernel mailing list, Marcelo Tosatti On Wed, 17 Sep 2003, Benjamin Herrenschmidt wrote: > Unfortunately, the wallstreet doesn't work neither. I get something strange on the > screen. It's somewhat sync'ed but divided in 4 vertical stripes, each one displaying > the left side of the display (+/- offseted), along with some fuzziness (clock wrong). > > XFree86 "ati" driver works fine (and manages somewhat to probe the panel type > and clocks properly ...) > > It's an LT-G (0x4c47 rev 0x80), 14.31818 XTAL, 230Mhz PLL, 63Mhz MCLK & XCLK > (so far it sounds good), mode properly detected (1024x768-60 from the mac > sense values read in nvram) but the display isn't correct. > > I can do register dumps to compare, though I may not have time until next week. Ok, this is the first serious problem, this was not were I expected the problems. The Rage LT should not be treated differently than before, no changes made here. The first thing to do is to check is if the clock programming code is the problem. Try to modprobe with "default_mclk=-1 default_xclk=-1" or use equivalent kernel command line options. If clock programming code should be blamed, the next step is to enable the debug define and check which clock registers are modified. You can try to revert my changes at mach64_ct.c line 375 and 433 to see if that changes something. If X corrects the display after starting, the problem might be due to the mode setting code. In that case the display should corrupt again when switching back to the console. Greetings, Daniël Mantione ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-17 20:42 ` Daniël Mantione @ 2003-09-17 21:12 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 15+ messages in thread From: Benjamin Herrenschmidt @ 2003-09-17 21:12 UTC (permalink / raw) To: Daniël Mantione; +Cc: linux-kernel mailing list, Marcelo Tosatti > The first thing to do is to check is if the clock programming code is the > problem. Try to modprobe with "default_mclk=-1 default_xclk=-1" or use > equivalent kernel command line options. Trying video=atyfb:mclk:-1,xclk:-1, same result Note that the xclk and mclk actually used by MacOS are 67.12Mhz, this may be different from the values setup by the firmware, on those old machines, the firmware uses 'approximative' values at best while the MacOS driver has the optimal ones. (Those machines had MacOS partially in ROM and never really went to the firmware for display except if you use linux ;) > If clock programming code should be blamed, the next step is to enable the > debug define and check which clock registers are modified. You can > try to revert my changes at mach64_ct.c line 375 and 433 to see if that > changes something. Reverting these didn't help neither > If X corrects the display after starting, the problem might be due to the > mode setting code. In that case the display should corrupt again when > switching back to the console. It does indeed. Here's the debug output: atyfb: using auxiliary register aperture atyfb: 3D RAGE LT-G [0x4c47 rev 0x80] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 63 Mhz MCLK, 63 Mhz XCLK BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF CLOCK_CNTL 7b23a040 87010182 003210b7 25000001 03000200 003807c0 00b00510 001a0a03 PLL cd d5 1a 14 72 03 40 fd 8e 9e 76 01 a6 00 00 00 06 a8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cd d5 1a 14 72 03 40 fd BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF 7b23a040 87010182 003210b7 25000001 03000200 003807c0 00b00510 PLL cd d5 1f 14 88 03 40 fd 8e 9e 76 01 a6 1b 00 00 06 a8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cd d5 1f 14 88 03 40 fd atyfb: monitor sense=51e, mode 7 Console: switching to colour frame buffer device 128x48 fb0: ATY Mach64 frame buffer device on PCI ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-17 20:07 ` Patch: Make iBook1 work again Benjamin Herrenschmidt 2003-09-17 20:42 ` Daniël Mantione @ 2003-09-17 21:10 ` Daniël Mantione 2003-09-17 21:23 ` Benjamin Herrenschmidt 1 sibling, 1 reply; 15+ messages in thread From: Daniël Mantione @ 2003-09-17 21:10 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linux-kernel mailing list, Marcelo Tosatti On Wed, 17 Sep 2003, Benjamin Herrenschmidt wrote: > Unfortunately, the wallstreet doesn't work neither. I get something strange on the > screen. It's somewhat sync'ed but divided in 4 vertical stripes, each one displaying > the left side of the display (+/- offseted), along with some fuzziness (clock wrong). Actually, is the problem perhaps this: Let's assume we have columns numbered from 0 to 79 i.e. 00000000001111111111222222222233333333334444444444555555555566666666667777777777 01234567890123456789012345678901234567890123456789012345678901234567890123456789 Perhaps your display is like this: 00000000001111111111000000000011111111110000000000111111111100000000001111111111 01234567890123456789012345678901234567890123456789012345678901234567890123456789 ** ** ** ***** Around the areas marked with ** there can be a lot of noise. ?? If this is the case I know the cause. Greetings, Daniël ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-17 21:10 ` Daniël Mantione @ 2003-09-17 21:23 ` Benjamin Herrenschmidt 2003-09-17 21:49 ` Daniël Mantione 0 siblings, 1 reply; 15+ messages in thread From: Benjamin Herrenschmidt @ 2003-09-17 21:23 UTC (permalink / raw) To: Daniël Mantione; +Cc: linux-kernel mailing list, Marcelo Tosatti On Wed, 2003-09-17 at 23:10, Daniël Mantione wrote: > On Wed, 17 Sep 2003, Benjamin Herrenschmidt wrote: > > > Unfortunately, the wallstreet doesn't work neither. I get something strange on the > > screen. It's somewhat sync'ed but divided in 4 vertical stripes, each one displaying > > the left side of the display (+/- offseted), along with some fuzziness (clock wrong). > > Actually, is the problem perhaps this: It looks like this indeed. What is the cause you are thining about ? > Let's assume we have columns numbered from 0 to 79 i.e. > > 00000000001111111111222222222233333333334444444444555555555566666666667777777777 > 01234567890123456789012345678901234567890123456789012345678901234567890123456789 > > Perhaps your display is like this: > > 00000000001111111111000000000011111111110000000000111111111100000000001111111111 > 01234567890123456789012345678901234567890123456789012345678901234567890123456789 > ** ** ** ***** > > Around the areas marked with ** there can be a lot of noise. > > ?? > > > If this is the case I know the cause. > > Greetings, > > Daniël -- Benjamin Herrenschmidt <benh@kernel.crashing.org> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-17 21:23 ` Benjamin Herrenschmidt @ 2003-09-17 21:49 ` Daniël Mantione 2003-09-18 8:00 ` Daniël Mantione 0 siblings, 1 reply; 15+ messages in thread From: Daniël Mantione @ 2003-09-17 21:49 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons On Wed, 17 Sep 2003, Benjamin Herrenschmidt wrote: > On Wed, 2003-09-17 at 23:10, Daniël Mantione wrote: > > On Wed, 17 Sep 2003, Benjamin Herrenschmidt wrote: > > > > > Unfortunately, the wallstreet doesn't work neither. I get something strange on the > > > screen. It's somewhat sync'ed but divided in 4 vertical stripes, each one displaying > > > the left side of the display (+/- offseted), along with some fuzziness (clock wrong). > > > > Actually, is the problem perhaps this: > It looks like this indeed. What is the cause you are thining about ? It is a misconfigured display fifo. Some of the Mach64 variants calculate the parameters for the display fifo automatically, others require the driver to do so. It's a very lowlevel kind of stuff and also gives you grey hairs quickly. When the CRT controller starts a scanline, it starts at the start of the display fifo and treats it as ring buffer. Before the CRT controller starts the buffer is filled with data from the framebuffer. You have to program the interval after which the buffer has to be filled with the next group of bytes from memory. If it is not calculated well, you get these problems. The original display fifo calculation caused problems on my Rage LT pro in all 24 and 32 bpp modes. Later it became clear that Geert's VAIO had these problems the common video modes like 640x480x8 and I started looking for fixes. After a lot of experimenting with the original Atyfb code, ATi's ltmodset program and the code in X, it became clear that the X code gave the best results, it only failed in VGA text modes at non standard resolutions. I contacted Marc Aurele la France about how he wrote them. Marc clearly did understood the matter very well and showed me an ATi internal document that described the situation a bit in more detail than the official documentation. So I decided to use the same code that X uses. So, to fix this we can look at the X driver, I must have made an error somewhere. Greetings, Daniël Mantione ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-17 21:49 ` Daniël Mantione @ 2003-09-18 8:00 ` Daniël Mantione 2003-09-18 9:03 ` Benjamin Herrenschmidt 2003-09-18 20:23 ` Benjamin Herrenschmidt 0 siblings, 2 replies; 15+ messages in thread From: Daniël Mantione @ 2003-09-18 8:00 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons On Wed, 17 Sep 2003, Daniël Mantione wrote: > So, to fix this we can look at the X driver, I must have made an error > somewhere. I found a problem, but it would mean that it was already broken before my patch. X does this test to check if a chip has 24 bit or a 32 bit precision display fifo settings: if (pATI->Chip < ATI_CHIP_264VT4) { pATI->XCLKPageFaultDelay += 2; pATI->XCLKMaxRASDelay += 3; pATI->DisplayFIFODepth = 24; } In atichip.h, ATI_CHIP_264LT is smaller than ATI_CHIP_264VT4, so according to the X sources, the Mach64 LT has a fifo depth 24. Now my code: if (M64_HAS(FIFO_24)) { info->fifo_size = 24; info->xclkpagefaultdelay += 2; info->xclkmaxrasdelay += 3; } else { info->fifo_size = 32; }; That looks ok. But look at the aty_chips table: { 0x4c47, 0x4c47, 0x00, 0x00, m64n_ltg, 230, 63, 63, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_LT_SLEEP | M64F_G3_PB_1024x768 }, The Mach64 LT does not have the M64F_FIFO_24 flag set! That will result in completely different values to be calculated and cause a distorted display. Greetings, Daniël Mantione ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-18 8:00 ` Daniël Mantione @ 2003-09-18 9:03 ` Benjamin Herrenschmidt 2003-09-18 20:23 ` Benjamin Herrenschmidt 1 sibling, 0 replies; 15+ messages in thread From: Benjamin Herrenschmidt @ 2003-09-18 9:03 UTC (permalink / raw) To: Daniël Mantione Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons On Thu, 2003-09-18 at 10:00, Daniël Mantione wrote: > On Wed, 17 Sep 2003, Daniël Mantione wrote: > > > So, to fix this we can look at the X driver, I must have made an error > > somewhere. > > I found a problem, but it would mean that it was already broken before my > patch. Yes, that's weird as it did work before your patch... Anyway, I cannot test until i'm back home tonight. I'll let you know. Regards, Ben. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-18 8:00 ` Daniël Mantione 2003-09-18 9:03 ` Benjamin Herrenschmidt @ 2003-09-18 20:23 ` Benjamin Herrenschmidt 2003-09-18 22:06 ` Daniël Mantione 1 sibling, 1 reply; 15+ messages in thread From: Benjamin Herrenschmidt @ 2003-09-18 20:23 UTC (permalink / raw) To: Daniël Mantione Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons > The Mach64 LT does not have the M64F_FIFO_24 flag set! That will result in > completely different values to be calculated and cause a distorted > display. I confirm, problem fixed ;) Ben. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-18 20:23 ` Benjamin Herrenschmidt @ 2003-09-18 22:06 ` Daniël Mantione 2003-09-19 6:57 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 15+ messages in thread From: Daniël Mantione @ 2003-09-18 22:06 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons On Thu, 18 Sep 2003, Benjamin Herrenschmidt wrote: > > > The Mach64 LT does not have the M64F_FIFO_24 flag set! That will result in > > completely different values to be calculated and cause a distorted > > display. > > I confirm, problem fixed ;) Great! I'm a bit puzzled how it could work before; it might be accidentally or the old code was tweaked and tweaked till the timings seemed to work, but at the cost of working in the generic case. It might explain why the code deviated so much from the formulas in the documentation. It also makes me think of the 63 MHz clock speed, as you did indicate it should be 67 MHz. Knowing that the memory clock speed is used in the display fifo calculation, I wonder if it was tweaked to get things right. Enough speculation, I'll post a patch asap, but I have currently no Linux machines around me. Expect a patch tomorrow. Greetings, Daniël Mantione ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-18 22:06 ` Daniël Mantione @ 2003-09-19 6:57 ` Benjamin Herrenschmidt 2003-09-19 7:09 ` Daniël Mantione 0 siblings, 1 reply; 15+ messages in thread From: Benjamin Herrenschmidt @ 2003-09-19 6:57 UTC (permalink / raw) To: Daniël Mantione Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons > It also makes me think of the 63 MHz clock speed, as you did indicate it > should be 67 MHz. Knowing that the memory clock speed is used in the display > fifo calculation, I wonder if it was tweaked to get things right. > > Enough speculation, I'll post a patch asap, but I have currently no Linux > machines around me. Expect a patch tomorrow. Don't change the clock speeds for now. I'll do some more tests with 67Mhz clocks to make sure it's ok, but since I won't be able to do that until wedenesday next week, let's get a known working version in asap. Also, I just got confirmation that the 101 PowerBook with an LT-Pro works fine as well. The only additional "fix" I have here is some bts making the sleep code slightly more robust (by preventing things like blank from touching chip registers when the chip is asleep if the blank timer triggers after sleep callback, same goes for cursor etc...) There is no emergency getting that in. It would be nice if that fixes could make it to 2.4.23 final, but I can send a separate patch later. Ben. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-19 6:57 ` Benjamin Herrenschmidt @ 2003-09-19 7:09 ` Daniël Mantione 2003-09-19 7:40 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 15+ messages in thread From: Daniël Mantione @ 2003-09-19 7:09 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons On Fri, 19 Sep 2003, Benjamin Herrenschmidt wrote: > > > It also makes me think of the 63 MHz clock speed, as you did indicate it > > should be 67 MHz. Knowing that the memory clock speed is used in the display > > fifo calculation, I wonder if it was tweaked to get things right. > > > > Enough speculation, I'll post a patch asap, but I have currently no Linux > > machines around me. Expect a patch tomorrow. > > Don't change the clock speeds for now. I'll do some more tests with > 67Mhz clocks to make sure it's ok, but since I won't be able to do > that until wedenesday next week, let's get a known working version > in asap. Indeed, we cannot change clocks because of results of only one machine. It just makes me wonder. Perhaps the best thing to do is to check this with ATi too. > Also, I just got confirmation that the 101 PowerBook with > an LT-Pro works fine as well. Nice! > The only additional "fix" I have here is some bts making the sleep > code slightly more robust (by preventing things like blank from > touching chip registers when the chip is asleep if the blank timer > triggers after sleep callback, same goes for cursor etc...) > There is no emergency getting that in. It would be nice if that > fixes could make it to 2.4.23 final, but I can send a separate patch > later. Okay.... By the way, how shall we get the powermanagement code to work on x86? As far as I saw that register backlight procedure exists only on PowerPC. Greetings, Daniël Mantione ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-19 7:09 ` Daniël Mantione @ 2003-09-19 7:40 ` Benjamin Herrenschmidt 2003-09-19 8:29 ` Daniël Mantione 0 siblings, 1 reply; 15+ messages in thread From: Benjamin Herrenschmidt @ 2003-09-19 7:40 UTC (permalink / raw) To: Daniël Mantione Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons > Indeed, we cannot change clocks because of results of only one machine. It > just makes me wonder. Perhaps the best thing to do is to check this with > ATi too. I need a brown paper bag here. A while ago (maybe 3 years), ATI send me a list of RefClk/MCLK/XCLK for their entire line of Mac chips with the Open Firmware node name so we could identify them. Some way, I lost that list (disk crash)... It was covering all "Mac" mach64 boards and a bunch of the r128 ones iirc. We don't need that as badly on recent machines as recent ATI cards provide the RefClk in the device-tree and we don't need to mess with the MLCK/XCLK any more on radeons. > Okay.... By the way, how shall we get the powermanagement code to work on > x86? As far as I saw that register backlight procedure exists only on PowerPC. The backlight "core" is a simple thing I did for PowerBook (since the backlight can be either done by the ATI chip or by some other uController on the motherboard). This current implementation is only suitable for a single panel and isn't something worth extending I beleive. Better would be to add proper backlight/frontlight/contrast control to 2.6 via the generic monitor infrastructure, maybe via sysfs. This covers more than just laptops: Flat panels on ADC/DVI can have USB controlled backlight, things like CRT iMacs have a chip that allow to control brightness & all of the geometry settings via i2c etc... We would need a common interface to userland for these at least, even if the actual implementation in the drivers is full of platform specific hooks, there is not much we can do about it for now I'm afraid. The sleep code is something specific to the way those chips are put to sleep on Macs. AFAIK, their clock is removed but not their power. I don't know if that can be useful on any x86 laptop... Ben. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-19 7:40 ` Benjamin Herrenschmidt @ 2003-09-19 8:29 ` Daniël Mantione 2003-09-19 8:38 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 15+ messages in thread From: Daniël Mantione @ 2003-09-19 8:29 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons On Fri, 19 Sep 2003, Benjamin Herrenschmidt wrote: > I need a brown paper bag here. A while ago (maybe 3 years), ATI send me > a list of RefClk/MCLK/XCLK for their entire line of Mac chips with the > Open Firmware node name so we could identify them. Some way, I lost that > list (disk crash)... It was covering all "Mac" mach64 boards and a bunch > of the r128 ones iirc. We don't need that as badly on recent machines as > recent ATI cards provide the RefClk in the device-tree Well, we don't need it on Mach64 either. It's just that the current code starts reprogramming the clocks; allthough the BIOS/firmware already does a fine job. The advantage of the current code is that we have built-in overclking facilities and perhaps that the chips can be initialized in very lowlevel situations where the BIOS/firmware did not initialize yet. But it is a bit questionable if that works at all; especially the Rage chips have a lot of vital registers that atyfb does not touch. > and we don't need to mess with the MLCK/XCLK any more on radeons. Actually I think we need that urgently. I cannot have my Inspiron 4500 laptop (Radeon 7500) on my, ehm, what's the english word, upper legs or something, for along time, the amount of heat generated is incredible. In Windows this is not a problem, only when you start playing games it gets hot. > > Okay.... By the way, how shall we get the powermanagement code to work on > > x86? As far as I saw that register backlight procedure exists only on PowerPC. > > The backlight "core" is a simple thing I did for PowerBook (since the > backlight can be either done by the ATI chip or by some other uController > on the motherboard). This current implementation is only suitable for > a single panel and isn't something worth extending I beleive. > > Better would be to add proper backlight/frontlight/contrast control to > 2.6 via the generic monitor infrastructure, maybe via sysfs. This covers > more than just laptops: Flat panels on ADC/DVI can have USB controlled > backlight, things like CRT iMacs have a chip that allow to control > brightness & all of the geometry settings via i2c etc... We would need > a common interface to userland for these at least, even if the actual > implementation in the drivers is full of platform specific hooks, there > is not much we can do about it for now I'm afraid. > The sleep code is something specific to the way those chips are put > to sleep on Macs. AFAIK, their clock is removed but not their power. > I don't know if that can be useful on any x86 laptop... I have some experience with that. Because of the way the Atyfb is currently designed, mclk could be an artbitrary value and adding XCLK to the table would mean XCLK could be an arbitrary value. But without using SCLK, they need to be relative to each other i.e. 1/2 3/4 2/3 etc. Luckily the BIOS on my Rage LT Pro did use SCLK to clock the engine, without that I would never had solved this. And I never found any other card that did use SCLK by default. By having the engine clocked by SCLK instead of MCLK, you can have both frequencies completely independend, just like what was needed. It was easier said than done, everytime I did submit code to someone I got the reply the computer did crash. I was unable to get this resolved until I had a Dell laptop temporarily available to me, which did not crash allways, it was just completely random wether the driver would load or not. As far as I believe now, after you start the SCLK, it doesn't work at once. You have to wait a while before a good clock signal is generated. Adding a primitive wait loop did solve the problem for about anyone. The conclusion is that the chip cannot be without clock signal even for a very short time and it even locks up the AGP so the rest of the computer hangs. It must be possible to stop the clock; I have a Rage IIc here with a broken BIOS, experiments on it show that you can enable the chip using the PCI registers without any clock running. Of course I never got the card to display anything. Greetings, Daniël Mantione ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Patch: Make iBook1 work again 2003-09-19 8:29 ` Daniël Mantione @ 2003-09-19 8:38 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 15+ messages in thread From: Benjamin Herrenschmidt @ 2003-09-19 8:38 UTC (permalink / raw) To: Daniël Mantione Cc: linux-kernel mailing list, Marcelo Tosatti, James Simmons > > and we don't need to mess with the MLCK/XCLK any more on radeons. > > Actually I think we need that urgently. I cannot have my Inspiron 4500 > laptop (Radeon 7500) on my, ehm, what's the english word, upper legs or > something, for along time, the amount of heat generated is incredible. > In Windows this is not a problem, only when you start playing games it gets hot. You don't need tweaking those clock neither. The mobility chips have dynamic clock & power management capabilities. I have code in radeonfb to enable those, unfortunately, we (recent radeonfb's and XFree) will disable most of those features because of some ASIC rev. bugs. We should ask ATI some more precise list of which revs are affected and if there's a better workaround... > I have some experience with that. > > Because of the way the Atyfb is currently designed, mclk could be an > artbitrary value and adding XCLK to the table would mean XCLK could be an > arbitrary value. But without using SCLK, they need to be relative to each > other i.e. 1/2 3/4 2/3 etc. > > Luckily the BIOS on my Rage LT Pro did use SCLK to clock the engine, > without that I would never had solved this. And I never found any other > card that did use SCLK by default. By having the engine clocked > by SCLK instead of MCLK, you can have both frequencies completely > independend, just like what was needed. > > It was easier said than done, everytime I did submit code to someone I got > the reply the computer did crash. I was unable to get this resolved until > I had a Dell laptop temporarily available to me, which did not crash > allways, it was just completely random wether the driver would load or > not. > > As far as I believe now, after you start the SCLK, it doesn't work at > once. You have to wait a while before a good clock signal is generated. > Adding a primitive wait loop did solve the problem for about anyone. Yup, a PLL need time to properly stabilize, especially older ones. > The conclusion is that the chip cannot be without clock signal even for a > very short time and it even locks up the AGP so the rest of the computer > hangs. > > It must be possible to stop the clock; I have a Rage IIc here with a > broken BIOS, experiments on it show that you can enable the chip using the > PCI registers without any clock running. Of course I never got the card to > display anything. By default, I think, the chip clocks itself on the PCI clock on powerup (without BIOS). From that, you can then configure the PLLs, switch to PLL derived clocks, initialize the memory controller, and go on... But for mobility chips, there are additional "automatic" clock control features, especially on r128 (M3) and radeons (M6/7/9/10) though I suppose M1 may have similar features. Look at the code in my version of radeonfb (2.4, it's not yet in 2.6 mainstream). I _much_ prefer using those features than tweaking the PLLs, especially on those new chips. Ben. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-09-19 8:38 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.44.0309162303490.32610-100000@deadlock.et.tudelft.nl>
2003-09-17 20:07 ` Patch: Make iBook1 work again Benjamin Herrenschmidt
2003-09-17 20:42 ` Daniël Mantione
2003-09-17 21:12 ` Benjamin Herrenschmidt
2003-09-17 21:10 ` Daniël Mantione
2003-09-17 21:23 ` Benjamin Herrenschmidt
2003-09-17 21:49 ` Daniël Mantione
2003-09-18 8:00 ` Daniël Mantione
2003-09-18 9:03 ` Benjamin Herrenschmidt
2003-09-18 20:23 ` Benjamin Herrenschmidt
2003-09-18 22:06 ` Daniël Mantione
2003-09-19 6:57 ` Benjamin Herrenschmidt
2003-09-19 7:09 ` Daniël Mantione
2003-09-19 7:40 ` Benjamin Herrenschmidt
2003-09-19 8:29 ` Daniël Mantione
2003-09-19 8:38 ` Benjamin Herrenschmidt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox