2004-01-01 18:55:25

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: 2.6.0: atyfb broken

On Tue, 30 Dec 2003, Claas Langbehn wrote:
> I have got an HP omnibook 4150B. When booting with atyfb,
> the kernel messages look great:
>
> atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 50 Mhz MCLK
> fb0: ATY Mach64 frame buffer device on PCI
>
> But either the screen is black and I see only the cursor and Background
> colors (CONFIG_FRAMEBUFFER_CONSOLE disabled), but X11 starts fine.

Does your notebook work with the atyfb in 2.4.23? With the one in 2.4.22 and
earlier?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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


2004-01-01 22:01:21

by Claas Langbehn

[permalink] [raw]
Subject: Re: 2.6.0: atyfb broken

Hello Geert,

> > I have got an HP omnibook 4150B. When booting with atyfb,
> > the kernel messages look great:
> >
> > atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 50 Mhz MCLK
> > fb0: ATY Mach64 frame buffer device on PCI
> >
> > But either the screen is black and I see only the cursor and Background
> > colors (CONFIG_FRAMEBUFFER_CONSOLE disabled), but X11 starts fine.
>
> Does your notebook work with the atyfb in 2.4.23? With the one in 2.4.22 and
> earlier?

with 2.4.23 it does not work either.

dmesg says:

atyfb: using auxiliary register aperture
atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
atyfb: BIOS contains driver information table.
atyfb: colour active matrix monitor detected: CPT CLAA141XB01
id=10, 1024x768 pixels, 262144 colours (LT mode)
supports 60 Hz refresh rates, default 60 Hz
LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6
atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL,
230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK
Console: switching to colour frame buffer device 80x25
fb0: ATY Mach64 frame buffer device on PCI


When booting the screen gets slowly flooded with white.
X11 works anyway.

dmesg's output shows different MCLK and XCLK with kernel 2.4.23
(see above).


Regards,claas

2004-01-02 12:44:23

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: 2.6.0: atyfb broken

On Thu, 1 Jan 2004, Claas Langbehn wrote:
> > > I have got an HP omnibook 4150B. When booting with atyfb,
> > > the kernel messages look great:
> > >
> > > atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 50 Mhz MCLK
> > > fb0: ATY Mach64 frame buffer device on PCI
> > >
> > > But either the screen is black and I see only the cursor and Background
> > > colors (CONFIG_FRAMEBUFFER_CONSOLE disabled), but X11 starts fine.
> >
> > Does your notebook work with the atyfb in 2.4.23? With the one in 2.4.22 and
> > earlier?
>
> with 2.4.23 it does not work either.
>
> dmesg says:
>
> atyfb: using auxiliary register aperture
> atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
> atyfb: BIOS contains driver information table.
> atyfb: colour active matrix monitor detected: CPT CLAA141XB01
> id=10, 1024x768 pixels, 262144 colours (LT mode)
> supports 60 Hz refresh rates, default 60 Hz
> LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6
> atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL,
> 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK
> Console: switching to colour frame buffer device 80x25
> fb0: ATY Mach64 frame buffer device on PCI
>
>
> When booting the screen gets slowly flooded with white.
> X11 works anyway.
>
> dmesg's output shows different MCLK and XCLK with kernel 2.4.23
> (see above).

Does it work with 2.4.22 and earlier? Mobility support was changed a lot in
2.4.23.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

2004-01-02 15:36:44

by Daniël Mantione

[permalink] [raw]
Subject: Re: 2.6.0: atyfb broken



On Fri, 2 Jan 2004, Geert Uytterhoeven wrote:

> > with 2.4.23 it does not work either.
> >
> > dmesg says:
> >
> > atyfb: using auxiliary register aperture
> > atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
> > atyfb: BIOS contains driver information table.
> > atyfb: colour active matrix monitor detected: CPT CLAA141XB01
> > id=10, 1024x768 pixels, 262144 colours (LT mode)
> > supports 60 Hz refresh rates, default 60 Hz
> > LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6
> > atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL,
> > 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK
> > Console: switching to colour frame buffer device 80x25
> > fb0: ATY Mach64 frame buffer device on PCI
> >
> >
> > When booting the screen gets slowly flooded with white.
> > X11 works anyway.
> >
> > dmesg's output shows different MCLK and XCLK with kernel 2.4.23
> > (see above).
>
> Does it work with 2.4.22 and earlier? Mobility support was changed a lot in
> 2.4.23.

Did this laptop work before? My first guess is no. Both 2.4.22 and 2.6.0
do not support LCD displays.

2.4.23 does, and is the only kernel that does have a chance of working.

In case 2.4.22 did work (possible since 720x400 VGA text mode is
converted in hardware to 640x400, and therefore very similar to 640x480
in timings), it will work very badly, the image is most likely not
correct and any attempt to switch video mode will fail.

The mclk/xclk settings in 2.4.23 are the correct default clock
frequencies (checked with ATi). Other kernel versions use
timings for an Apple Powerbook, which, because the open firmware
initializes a correct startup video mode and PowerPC specific code that
prevents switching to 640x480 will work with the original driver.
This Apple laptop is detected in 2.4.23 and still gets the original
frequencies.

Anyway, the frequencies are correct for your laptop, if the display is
fading white it means the graphics chip is operating correctly but
provide wrong video mode timings to your LCD display.

Dani?l

2004-01-03 23:37:30

by Claas Langbehn

[permalink] [raw]
Subject: Re: 2.6.0: atyfb broken

Hello!


> > Does it work with 2.4.22 and earlier? Mobility support was changed a lot in
> > 2.4.23.

No, 2.4.22 does not work either. It has also screen-flickering.

2.6.0 seems to be closest to a working solution.

( CONFIG_FB_ATY, CONFIG_FB_ATY_CT and CONFIG_FB_ATY_XL_INIT switched on,
CONFIG_FRAMEBUFFER_CONSOLE disabled)


bye, claas

2004-01-04 00:27:34

by Daniël Mantione

[permalink] [raw]
Subject: Re: 2.6.0: atyfb broken



On Sun, 4 Jan 2004, Claas Langbehn wrote:

> Hello!
>
>
> > > Does it work with 2.4.22 and earlier? Mobility support was changed a lot in
> > > 2.4.23.
>
> No, 2.4.22 does not work either. It has also screen-flickering.

Ok, that was expected; this most likely is because of the initialisation
code in 2.4.22; it is completely unsuitable for the Mobility M1 and programs
very bad values into the chip.

> 2.6.0 seems to be closest to a working solution.

Not at all. Your laptop has an LCD display. Unlike CRTs, LCD displays have
a fixed resolution; you LCD display has 1024x768 pixels. Because the
display is completely digital, the display needs its pixel data send at
a fixed rate, enforcing also the refresh rate, 60 Hz in your case.

(LCD monitors with VGA-connectors have special chips that adapt the
resolution and refresh rate of a VGA signal to the video mode desired by
the panel. Image quality suffers badly)

Because of this, a traditional video driver will fail on such a display.
I.e. Atyfb switches to 640x480 60 Hz, which is completely different from
what your display accepts, and it won't work.

Because of some VGA compatibility stuff normal 720x400 VGA text mode is
downscaled to 640x400 by your laptop. Therefore, it is not too different
from 640x480 and on some computers it displays something. I experienced
this on my Rage LT pro, the image was completely wrong, the bottom part of
the screen was a mirror of the upper part.

Therefore, it might happen that 2.6.0 does display something
(initialization is different from 2.4.x), but 2.6.0 will not display a
correct image in any case.

Years ago I started making the Atyfb support LCD displays. It was a very
difficult project; I got my own laptop working more than 2 years ago,
after that slowly all the other machines I knew of started working.
However, it was only until recently before Geert's laptop did work; that was a
really stupborn one. The LCD registers on the chips are very tricky to set
right; the clock code (which was completely wrong) was even more tricky
to get right.

My work was included in 2.4.23. Therefore that kernel
is the only one which has any chance of working. Apparently
there still is an LCD specific issue with your laptop, which needs to be
debugged.

What to do?

The best thing you can try is to connect a CRT. Its a handy tool (it
eats any video mode, including wrong ones) to check if the driver does
something wrong. Use it to inspect geometry and the horizontal & vertical
refresh rates. The CRT should dislay 1024x768 60 Hz in all resolutions
(unless you switch off the LCD display).

Compile Atyfb as module. Use fbset to switch video modes blindly. Check
the following modes: 640x400, 640x480, 1024x768.

If everything is ok, we'll start to do some register debugging.

Dani?l

2004-01-04 00:52:50

by Claas Langbehn

[permalink] [raw]
Subject: Re: 2.6.0: atyfb broken

Hello Dani?l!

> What to do?
>
> The best thing you can try is to connect a CRT. Its a handy tool (it
> eats any video mode, including wrong ones) to check if the driver does
> something wrong. Use it to inspect geometry and the horizontal & vertical
> refresh rates. The CRT should dislay 1024x768 60 Hz in all resolutions
> (unless you switch off the LCD display).
>
> Compile Atyfb as module. Use fbset to switch video modes blindly. Check
> the following modes: 640x400, 640x480, 1024x768.

Okay, the external monitor was a good idea.
I can boot with the external monitor and atyfb.

when I do fbset 1024x768-60, then the screen gets distorted, then I hit
Fn + F5 (Monitor selection) several times, and finally I get a working
picture.

So tell me how we can do register debuggig.


Regards, claas

2004-01-04 09:40:38

by Daniël Mantione

[permalink] [raw]
Subject: Re: 2.6.0: atyfb broken



On Sun, 4 Jan 2004, Claas Langbehn wrote:

> > The best thing you can try is to connect a CRT. Its a handy tool (it
> > eats any video mode, including wrong ones) to check if the driver does
> > something wrong. Use it to inspect geometry and the horizontal & vertical
> > refresh rates. The CRT should dislay 1024x768 60 Hz in all resolutions
> > (unless you switch off the LCD display).
> >
> > Compile Atyfb as module. Use fbset to switch video modes blindly. Check
> > the following modes: 640x400, 640x480, 1024x768.

> Okay, the external monitor was a good idea.
> I can boot with the external monitor and atyfb.

2.4.23?

> when I do fbset 1024x768-60, then the screen gets distorted, then I hit
> Fn + F5 (Monitor selection) several times, and finally I get a working
> picture.

Ah you have a working fn-f5? good! fn-f5 will fix your display in most
cases, however, my experience is also that it can mess things up. If you
can get in 1024x768 without fn-f5 please try so, to make sure the chip is
in a clean state.

Remember to do all tests with both displays enabled. When you are in
1024x768 60 Hz, the hardware stretcher is disabled. Test if horizontal
stretching works:

fbset -xres 640

You can do this because the video timings are locked to
1024x768-60, and your refresh rate does not get a boost like with a
normal vga monitor. Because we only use 1 Crt controller, your external
monitor is locked too.

You should now have a 640x768 mode. Watch the image on the Crt display. It
should be rock stable during the mode switch the Crt should not be
detecting any mode change and the picture should not change position.

Switch back to 1024x768:

fbset -xres 1024

Now try the vertical streching:

fbset -yres 480

Check again very close what happens on your crt. It is my expectation that
one of these tests fails and the other will wok correctly.

> So tell me how we can do register debuggig.

I'll send you my register dump programs so you can compare the setting of
the Crt controller with fo example X video modes.

Dani?l