Re: [PATCH] 2.4.21-rc8 vesafb memory remapping...
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2003-06-27 11:38:52
Also in:
lkml
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:
quoted hunk
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
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php