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.
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
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
> 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
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 <[email protected]>
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
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
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.
> 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.
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
> 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.
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
> 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.
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
> > 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.