[PATCH] 2.4.21-rc8 vesafb memory remapping...

[PATCH] 2.4.21-rc8 vesafb memory remapping...

[Thomas Backlund]

I noticed that the vesafb still remaps memory according to a calculation 
done in bits, even if should be done in bytes...
This will remap more memory than old cards actually have...

An example:
My laptop has 8192 KB of videoram
I use it with videomode 1024x768x16

With current vesafb that will translate to 12288 KB remapping

So here is my suggestion,
either grab the complete "fix" from rc7-ac1 (wich calculates in bytes),
or If you dont like that, my second suggestion is to use the
old vesafb code to take care of old cards like this:

----- cut -----
#diff -u rc8/drivers/video/vesafb.c rc8/drivers/video/vesafb.c.new
--- rc8/drivers/video/vesafb.c  2003-06-12 23:13:29.000000000 +0300
+++ rc8/drivers/video/vesafb.c.new      2003-06-12 23:18:03.000000000 +0300
@@ -521,6 +521,11 @@
        video_height        = screen_info.lfb_height;
        video_linelength    = screen_info.lfb_linelength;
        video_size          = screen_info.lfb_width *   
screen_info.lfb_height * video_bpp;
+
+       /* check that we don't remap more memory than old cards have */
+       if (video_size > screen_info.lfb_size * 65536)
+               video_size = screen_info.lfb_size * 65536;
+
        video_visual = (video_bpp == 8) ?
                FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;

----- cut -----

Like this we would keep both old and new systems happy AFAIK...


-- 
Regards

Thomas Backlund

http://www.iki.fi/tmb/
tmb@iki.fi

Re: [PATCH] 2.4.21-rc8 vesafb memory remapping...

[Geert Uytterhoeven]

	Hi Marcelo,

Can we please have a fix for vesafb in the next -pre*? Currently it maps 8
times too much memory due to a bits/bytes confusion.

For your convenience, I rediffed against the latest trees and appended the
patch below. This includes the fixed vram size handling and the documentation
for the new vram parameter.

Thanks!

On Thu, 12 Jun 2003, Thomas Backlund wrote:
> I noticed that the vesafb still remaps memory according to a calculation 
> done in bits, even if should be done in bytes...
> This will remap more memory than old cards actually have...
> 
> An example:
> My laptop has 8192 KB of videoram
> I use it with videomode 1024x768x16
> 
> With current vesafb that will translate to 12288 KB remapping
> 
> So here is my suggestion,
> either grab the complete "fix" from rc7-ac1 (wich calculates in bytes),
> or If you dont like that, my second suggestion is to use the
> old vesafb code to take care of old cards like this:
> 
> ----- cut -----
> #diff -u rc8/drivers/video/vesafb.c rc8/drivers/video/vesafb.c.new
> --- rc8/drivers/video/vesafb.c  2003-06-12 23:13:29.000000000 +0300
> +++ rc8/drivers/video/vesafb.c.new      2003-06-12 23:18:03.000000000 +0300
> @@ -521,6 +521,11 @@
>         video_height        = screen_info.lfb_height;
>         video_linelength    = screen_info.lfb_linelength;
>         video_size          = screen_info.lfb_width *   
> screen_info.lfb_height * video_bpp;
> +
> +       /* check that we don't remap more memory than old cards have */
> +       if (video_size > screen_info.lfb_size * 65536)
> +               video_size = screen_info.lfb_size * 65536;
> +
>         video_visual = (video_bpp == 8) ?
>                 FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
> 
> ----- cut -----
> 
> Like this we would keep both old and new systems happy AFAIK...
> 
> 
> -- 
> Regards
> 
> Thomas Backlund
> 
> http://www.iki.fi/tmb/
> tmb@iki.fi

--- linux-2.4.22-pre2/drivers/video/vesafb.c	Fri May  9 11:03:41 2003
+++ linux-2.4.21-ac3/drivers/video/vesafb.c	Fri Jun 27 13:46:11 2003
@@ -94,6 +94,7 @@
 
 static int             inverse   = 0;
 static int             mtrr      = 0;
+static int	 vram __initdata = 0;	/* needed for vram boot option */
 static int             currcon   = 0;
 
 static int             pmi_setpal = 0;	/* pmi for palette changes ??? */
@@ -479,6 +480,10 @@
 			pmi_setpal=1;
 		else if (! strcmp(this_opt, "mtrr"))
 			mtrr=1;
+		/* checks for vram boot option */
+		else if (! strncmp(this_opt, "vram:", 5))
+			vram = simple_strtoul(this_opt+5, NULL, 0);
+
 		else if (!strncmp(this_opt, "font:", 5))
 			strcpy(fb_info.fontname, this_opt+5);
 	}
@@ -520,7 +525,20 @@
 	video_width         = screen_info.lfb_width;
 	video_height        = screen_info.lfb_height;
 	video_linelength    = screen_info.lfb_linelength;
-	video_size          = screen_info.lfb_width *	screen_info.lfb_height * video_bpp;
+
+	/* remap memory according to videomode, multiply by 2 to get space for doublebuffering */
+	video_size          = screen_info.lfb_width *	screen_info.lfb_height * video_bpp / 8 * 2;
+
+	/* check that we don't remap more memory than old cards have */
+	if (video_size > screen_info.lfb_size * 65536)
+		video_size = screen_info.lfb_size * 65536;
+	
+	/* FIXME: Should we clip against declared size for banked devices ? */
+	
+	/* sets video_size according to vram boot option */
+	if (vram && vram * 1024 * 1024 != video_size)
+		video_size = vram * 1024 * 1024;
+		
 	video_visual = (video_bpp == 8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
 
--- linux-2.4.22-pre2/Documentation/fb/vesafb.txt	Fri Jul 28 21:50:51 2000
+++ linux-2.4.21-ac3/Documentation/fb/vesafb.txt	Fri Jun 27 13:45:47 2003
@@ -139,13 +139,17 @@
 redraw	scroll by redrawing the affected part of the screen, this
 	is the safe (and slow) default.
 
-
 vgapal	Use the standard vga registers for palette changes.
 	This is the default.
 pmipal	Use the protected mode interface for palette changes.
 
 mtrr	setup memory type range registers for the vesafb framebuffer.
 
+vram:n  remap 'n' MiB of video RAM. If 0 or not specified, remap memory
+        according to video mode. (2.5.66 patch/idea by Antonino Daplas
+	reversed to give override possibility (allocate more fb memory
+	than the kernel would) to 2.4 by tmb@iki.fi)
+  
 
 Have fun!
 
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: [PATCH] 2.4.21-rc8 vesafb memory remapping...

[Alan Cox]

On Gwe, 2003-06-27 at 12:51, Geert Uytterhoeven wrote:
> 	Hi Marcelo,
> 
> Can we please have a fix for vesafb in the next -pre*? Currently it maps 8
> times too much memory due to a bits/bytes confusion.

You want to allocate a bit more than the minimum needed for the scroll
buffers and you also have to check for banked stuff. Thats fixed in -ac