* Re: [PATCH] 2.4.21-rc8 vesafb memory remapping...
2003-06-12 20:43 [PATCH] 2.4.21-rc8 vesafb memory remapping Thomas Backlund
@ 2003-06-27 11:51 ` Geert Uytterhoeven
2003-06-27 11:54 ` Alan Cox
0 siblings, 1 reply; 3+ messages in thread
From: Geert Uytterhoeven @ 2003-06-27 11:51 UTC (permalink / raw)
To: Marcelo Tosatti, Alan Cox, Thomas Backlund
Cc: Linux Kernel Development, Linux Frame Buffer Device Development
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
^ permalink raw reply [flat|nested] 3+ messages in thread