atyfb in 2.5.51

atyfb in 2.5.51

[Paul Mackerras]

I tried 2.5.51 on my G3 powerbook (laptop), which has a Rage LT Pro
video chip (ID 0x4c49 or LI).  With the patch below, atyfb compiles
and seems to mostly work.  However, I didn't see any penguin on boot.
Instead the top inch or so of the screen was just black.

X seems to be running just fine.  I have 'Option "UseFBDev"' in my
/etc/X11/XF86Config-4.  What doesn't work is changing VTs from X to a
text console.  If I press ctrl-alt-F1, for instance, the colormap
changes but I don't see anything get redrawn.  The screen looks just
like what I had in X but with the altered colormap.  If I then press
alt-F7, it switches back to X and X redraws the screen properly and
restores its colormap.

The other worrying thing is that on two occasions now the machine has
oopsed in free_block(), called from reap_timer_fnc(), because it has
dereferenced a bogus pointer value.  When I look at the memory that it
read the pointer from, it looks like a console screen buffer, that is,
the bytes are alternately 0x07 and ascii characters that look like a
login prompt.  This happened when waking the machine up from sleep and
when exiting X.  It sounds to me like you are freeing a console screen
buffer and then continuing to use it.

The patch below also takes out the CONFIG_NVRAM stuff since it doesn't
work and I don't believe anyone has ever used it.

I have also tried aty128fb with some local patches to get it to
compile for my G4 powerbook.  It also doesn't draw the penguin, and it
oopses when X starts, for some reason.

Regards,
Paul.

diff -urN linux-2.5/drivers/video/aty/atyfb_base.c pmac-2.5/drivers/video/aty/atyfb_base.c
--- linux-2.5/drivers/video/aty/atyfb_base.c	2002-12-10 15:29:52.000000000 +1100
+++ pmac-2.5/drivers/video/aty/atyfb_base.c	2002-12-11 09:16:11.000000000 +1100
@@ -70,7 +70,7 @@
 
 #ifdef __powerpc__
 #include <asm/prom.h>
-#include <video/macmodes.h>
+#include "../macmodes.h"	/* XXX relative include, yuck */
 #endif
 #ifdef __sparc__
 #include <asm/pbm.h>
@@ -84,9 +84,6 @@
 #ifdef CONFIG_BOOTX_TEXT
 #include <asm/btext.h>
 #endif
-#ifdef CONFIG_NVRAM
-#include <linux/nvram.h>
-#endif
 #ifdef CONFIG_PMAC_BACKLIGHT
 #include <asm/backlight.h>
 #endif
@@ -226,14 +223,9 @@
 #endif
 
 #ifdef CONFIG_PPC
-#ifdef CONFIG_NVRAM_NOT_DEFINED
-static int default_vmode __initdata = VMODE_NVRAM;
-static int default_cmode __initdata = CMODE_NVRAM;
-#else
 static int default_vmode __initdata = VMODE_CHOOSE;
 static int default_cmode __initdata = CMODE_CHOOSE;
 #endif
-#endif
 
 #ifdef CONFIG_ATARI
 static unsigned int mach64_count __initdata = 0;
@@ -1412,16 +1404,16 @@
 static int aty_sleep_notify(struct pmu_sleep_notifier *self, int when)
 {
 	struct fb_info *info;
-	struct atyfb_par *par = (struct atyfb_par *) info->fb.par;
+	struct atyfb_par *par;
 	int result;
 
 	result = PBOOK_SLEEP_OK;
 
 	for (info = first_display; info != NULL; info = par->next) {
-		struct fb_fix_screeninfo fix;
 		int nb;
 
-		nb = fb_display[fg_console].var.yres * info->fix.line_length;
+		par = (struct atyfb_par *) info->par;
+		nb = info->var.yres * info->fix.line_length;
 
 		switch (when) {
 		case PBOOK_SLEEP_REQUEST:
@@ -1439,7 +1431,7 @@
 			if (par->blitter_may_be_busy)
 				wait_for_idle(par);
 			/* Stop accel engine (stop bus mastering) */
-			if (par->accel_flags & FB_ACCELF_TEXT)
+			if (info->var.accel_flags & FB_ACCELF_TEXT)
 				aty_reset_engine(par);
 
 			/* Backup fb content */
@@ -1844,14 +1836,6 @@
 			    (&var, info, mode_option, 8))
 				var = default_var;
 		} else {
-#ifdef CONFIG_NVRAM
-			if (default_vmode == VMODE_NVRAM) {
-				default_vmode = nvram_read_byte(NV_VMODE);
-				if (default_vmode <= 0
-				    || default_vmode > VMODE_MAX)
-					default_vmode = VMODE_CHOOSE;
-			}
-#endif
 			if (default_vmode == VMODE_CHOOSE) {
 				if (M64_HAS(G3_PB_1024x768))
 					/* G3 PowerBook with 1024x768 LCD */
@@ -1873,10 +1857,6 @@
 			if (default_vmode <= 0
 			    || default_vmode > VMODE_MAX)
 				default_vmode = VMODE_640_480_60;
-#ifdef CONFIG_NVRAM
-			if (default_cmode == CMODE_NVRAM)
-				default_cmode = nvram_read_byte(NV_CMODE);
-#endif
 			if (default_cmode < CMODE_8
 			    || default_cmode > CMODE_32)
 				default_cmode = CMODE_8;

Re: atyfb in 2.5.51

[Benjamin Herrenschmidt]

On Tue, 2002-12-10 at 23:31, Paul Mackerras wrote:
> I tried 2.5.51 on my G3 powerbook (laptop), which has a Rage LT Pro
> video chip (ID 0x4c49 or LI).  With the patch below, atyfb compiles
> and seems to mostly work.  However, I didn't see any penguin on boot.
> Instead the top inch or so of the screen was just black.
> 
> X seems to be running just fine.  I have 'Option "UseFBDev"' in my
> /etc/X11/XF86Config-4.

AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
Marc Aurele La France (maintainer of this driver) is basically allergic
to kernel fbdev support.

> What doesn't work is changing VTs from X to a
> text console.  If I press ctrl-alt-F1, for instance, the colormap
> changes but I don't see anything get redrawn.  The screen looks just
> like what I had in X but with the altered colormap.  If I then press
> alt-F7, it switches back to X and X redraws the screen properly and
> restores its colormap.

I don't know if happened with earlier fbdev versions for you, but one
possibility is that X reconfigures the display base, and possibly more
bits of the card's internal memory map. Either fbdev should restore
that, or adapt to what X set. On R128's and radeon's, this is things
like DISPLAY_BASE_ADDR.
 
> The patch below also takes out the CONFIG_NVRAM stuff since it doesn't
> work and I don't believe anyone has ever used it.

Yup, it's some wacky old pmac stuff that should be killed.
 
> I have also tried aty128fb with some local patches to get it to
> compile for my G4 powerbook.  It also doesn't draw the penguin, and it
> oopses when X starts, for some reason.

Hrm... I'll have to test radeonfb... It worked yesteday in console (I
don't remember about the penguin) but I didn't try X.
 

Re: atyfb in 2.5.51

[James Simmons]

> AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
> Marc Aurele La France (maintainer of this driver) is basically allergic
> to kernel fbdev support.

:-(

> I don't know if happened with earlier fbdev versions for you, but one
> possibility is that X reconfigures the display base, and possibly more
> bits of the card's internal memory map. Either fbdev should restore
> that, or adapt to what X set. On R128's and radeon's, this is things
> like DISPLAY_BASE_ADDR.

I will have to go threw the X code to fix that :-(

> > I have also tried aty128fb with some local patches to get it to
> > compile for my G4 powerbook.  It also doesn't draw the penguin, and it
> > oopses when X starts, for some reason.
>
> Hrm... I'll have to test radeonfb... It worked yesteday in console (I
> don't remember about the penguin) but I didn't try X.

No penguin. That is weird. I get the penguin on my ix86 box.

Re: atyfb in 2.5.51

[David S. Miller]

On Tue, 2002-12-10 at 22:18, James Simmons wrote:
> > AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
> > Marc Aurele La France (maintainer of this driver) is basically allergic
> > to kernel fbdev support.
> 
> :-(

I've always stated that the whole fbdev model was flawed, it makes
basic assumptions about how a video card's memory and registers are
accessed (ie. the programming model) and many popular cards absolutely
do not fit into that model.

> I will have to go threw the X code to fix that :-(

There is nothing to fix.  You simply must restore the video state when
the last mmap() client goes away.  The __sparc__ code does exactly that.

I think relying on an application that mmap's a card to perfectly
restore the state would work in a perfect world, one we do not live
in.  Furthermore, fixing up the state like I am suggesting makes life
much simpler for people actually working on things like X servers and
other programs directly programming the ATI chip.

Re: [Linux-fbdev-devel] Re: atyfb in 2.5.51

[Antonino Daplas]

On Wed, 2002-12-11 at 04:11, Benjamin Herrenschmidt wrote:
> 
> I don't know if happened with earlier fbdev versions for you, but one
> possibility is that X reconfigures the display base, and possibly more
> bits of the card's internal memory map. Either fbdev should restore
> that, or adapt to what X set. On R128's and radeon's, this is things
> like DISPLAY_BASE_ADDR.
>  
Although this is in the faqs for a long time, (behavior is undefined if
fbdev is used with software that touches the video card) this is an
issue that needs to be taken into consideration.  Without the set_var()
hook, fbcon will depend on the contents of info->var if there is a need
to touch the hardware or not.  And switching from X to the console will
not change the var, but since X actually did touch the hardware, you
just messed up your screen or worse, crashed the hardware.

Before, most drivers just unconditionally refresh the hardware at every
switch  during set_var(). I've been pointing this out for a long time
now, do we unconditionally do a check_var()/set_par() after every
console switch, or do we rely on fbdev and X cooperating with each
other? Or better, maybe fbcon has a way of knowing if the switch came
from  Xfree86.

Tony

Re: atyfb in 2.5.51

[James Simmons]

> I've always stated that the whole fbdev model was flawed, it makes
> basic assumptions about how a video card's memory and registers are
> accessed (ie. the programming model) and many popular cards absolutely
> do not fit into that model.

I agree that the design of the /dev/fbX interface is not the best.
Unfortunely we are stuck with it. Changing it would break userland apps.

> > I will have to go threw the X code to fix that :-(
>
> There is nothing to fix.  You simply must restore the video state when
> the last mmap() client goes away.  The __sparc__ code does exactly that.

I should of worded that better. Meaning I have to see what X is doing so
the fbdev driver sets the state itself better. Hm. I'm thinking about the
mmap approach versus the fb_open approach being used now.

> I think relying on an application that mmap's a card to perfectly
> restore the state would work in a perfect world, one we do not live
> in.  Furthermore, fixing up the state like I am suggesting makes life
> much simpler for people actually working on things like X servers and
> other programs directly programming the ATI chip.

:-( True. We should always assume X or any userland app could be broken.

Re: [Linux-fbdev-devel] Re: atyfb in 2.5.51

[James Simmons]

> Before, most drivers just unconditionally refresh the hardware at every
> switch  during set_var(). I've been pointing this out for a long time
> now, do we unconditionally do a check_var()/set_par() after every
> console switch, or do we rely on fbdev and X cooperating with each
> other? Or better, maybe fbcon has a way of knowing if the switch came
> from  Xfree86.

My next project is to fix this issue. I will be working on that today.

Re: atyfb in 2.5.51

[David S. Miller]

   From: James Simmons <jsimmons@infradead.org>
   Date: Wed, 11 Dec 2002 07:16:04 -0800 (PST)
   
   I agree that the design of the /dev/fbX interface is not the best.
   Unfortunely we are stuck with it. Changing it would break userland apps.
   
I totally understand.  I do not suggest to break fbdev in it's current
form, too much stuff uses it.

My main point was, don't be surprised the X servers, like the ATI
driver, don't use fbdev and instead just mmap the device and simply
program it directly.

fbdev is nice, in the specific cases where the device fits the fbdev
model, because once you have the kernel bits you have X support :)

Franks a lot,
David S. Miller
davem@redhat.com

Re: atyfb in 2.5.51

[Paul Mackerras]

James Simmons writes:

> :-( True. We should always assume X or any userland app could be broken.

I don't think we can blame X in this particular situation.  When I
press ctrl-alt-F1 in X, it resets the screen to the colormap and depth
that the text console was using, but the kernel doesn't redraw the
text console screen image.  (I presume it also resets the resolution,
but since I have only tried on an LCD screen I can't say for sure.)

Paul.

Re: atyfb in 2.5.51

[Alan Cox]

On Wed, 2002-12-11 at 20:43, David S. Miller wrote:
> fbdev is nice, in the specific cases where the device fits the fbdev
> model, because once you have the kernel bits you have X support :)

fbdev also can't be used in some situations on x86. Deeply fascinating
things happen on some x86 processors if you execute a loop of code with
an instruction that crosses two different memory types.

Re: atyfb in 2.5.51

[Pavel Machek]

Hi!

> On Wed, 2002-12-11 at 20:43, David S. Miller wrote:
> > fbdev is nice, in the specific cases where the device fits the fbdev
> > model, because once you have the kernel bits you have X support :)
> 
> fbdev also can't be used in some situations on x86. Deeply fascinating
> things happen on some x86 processors if you execute a loop of code with
> an instruction that crosses two different memory types.

Sounds like cpu bug to me? What cpus are affected?

Could be worked around by pointing debug register at memory boundary?

								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: atyfb in 2.5.51

[Geert Uytterhoeven]

On 11 Dec 2002, David S. Miller wrote:
> On Tue, 2002-12-10 at 22:18, James Simmons wrote:
> > > AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev.
> > > Marc Aurele La France (maintainer of this driver) is basically allergic
> > > to kernel fbdev support.
> > 
> > :-(
> 
> I've always stated that the whole fbdev model was flawed, it makes
> basic assumptions about how a video card's memory and registers are
> accessed (ie. the programming model) and many popular cards absolutely
> do not fit into that model.

Could you please elaborate so we have a chance to improve the model? Thanks!

In case you just mean graphics hardware (e.g. Creator) where you don't want to
provide direct access to the frame buffer, but do everything through the
acceleration engine, just set smem_start and smem_len both to 0.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: atyfb in 2.5.51

[Geert Uytterhoeven]

On 11 Dec 2002, Alan Cox wrote:
> On Wed, 2002-12-11 at 20:43, David S. Miller wrote:
> > fbdev is nice, in the specific cases where the device fits the fbdev
> > model, because once you have the kernel bits you have X support :)
> 
> fbdev also can't be used in some situations on x86. Deeply fascinating
> things happen on some x86 processors if you execute a loop of code with
> an instruction that crosses two different memory types.

Do you mean one load/store access to memory where the first and the last part
(e.g. first 2 and last 2 bytes for a 32-bit word) are to different memory types
(e.g. main RAM and video RAM on PCI)? If yes, where does that happen? If no,
can you please clarify?

(At first I thought you meant an instruction where the opcode crosses those
 two memory types, but we don't put code in video RAM...)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: atyfb in 2.5.51

[Alan Cox]

On Fri, 2002-12-13 at 08:53, Geert Uytterhoeven wrote:
> (At first I thought you meant an instruction where the opcode crosses those
>  two memory types, but we don't put code in video RAM...)

I did. The frame buffer drivers support mmap(). x86 has no "non-exec"
bit. So any user able to open /dev/fb can bring down such a box. Similar
things apply with early athlon and prefetching /dev/fb

Re: Re: atyfb in 2.5.51

[Stefan Reinauer]

* James Simmons <jsimmons@infradead.org> [021211 16:16]:
> 
> > I've always stated that the whole fbdev model was flawed, it makes
> > basic assumptions about how a video card's memory and registers are
> > accessed (ie. the programming model) and many popular cards absolutely
> > do not fit into that model.
> 
> I agree that the design of the /dev/fbX interface is not the best.
> Unfortunely we are stuck with it. Changing it would break userland apps.

One thing I was wondering: Is there a proper way to make sure that 
acceses to the framebuffer end up only on one specific virtual console?
I have an application that runs on one virtual console, but when
switching I do not want the screen to be trashed by writing just into
the framebuffer memory. My solution was to check whether the current
console is the console the application started on, but this looks a
bit bloated to me and I had some weird effects when switching to X and
back - like one frame still got painted into graphics memory while X was
already shown.
  
  Any ideas?
  Stefan

-- 
Laissez Faire Economics is the theory that if each acts like a vulture,
all will end as doves.



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: atyfb in 2.5.51

[Geert Uytterhoeven]

On 13 Dec 2002, Alan Cox wrote:
> On Fri, 2002-12-13 at 08:53, Geert Uytterhoeven wrote:
> > (At first I thought you meant an instruction where the opcode crosses those
> >  two memory types, but we don't put code in video RAM...)
> 
> I did. The frame buffer drivers support mmap(). x86 has no "non-exec"
> bit. So any user able to open /dev/fb can bring down such a box. Similar
> things apply with early athlon and prefetching /dev/fb

Weird... So it really crashes the box, not just throwing an exception?
On PPC you cannot use prefetching on non-cached memory, but if you try it won't
take down the whole box.

Then make sure /dev/fb is accessible by `trusted' users on such machines.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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