vesafb fix

Hi,

The patch below fixes some vesafb issues. Changes:

* fixed struct screen_info in tty.h to use portable types. "unsigned long" for 32bit values doesn't work on hammer machines ...
* limited the framebuffer memory used by vesafb to 16 MB. This avoids that vesafb's ioremap() eats plenty of kernel address space for no real benefit if the gfx card has very much memory (some have 128 MB or more, ia32 has 128 MB address space for vmalloc and ioremap ...).
* mtrr is enabled by default. That should improve the vesafb performance alot. Also added a option to disable mtrr.

please apply,

Gerd

@@ -51,7 +51,7 @@
 static u32 pseudo_palette[17];
 
 static int             inverse   = 0;
-static int             mtrr      = 0;
+static int             mtrr      = 1;
 
 static int             pmi_setpal = 0;	/* pmi for palette changes ??? */
 static int             ypan       = 0;  /* 0..nothing, 1..ypan, 2..ywrap */

@@ -208,6 +208,8 @@
 			pmi_setpal=1;
 		else if (! strcmp(this_opt, "mtrr"))
 			mtrr=1;
+		else if (! strcmp(this_opt, "nomtrr"))
+			mtrr=0;
 	}
 	return 0;
 }

@@ -231,6 +233,12 @@
 	vesafb_fix.visual   = (vesafb_defined.bits_per_pixel == 8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
 
+	/* limit framebuffer size to 16 MB.  Otherwise we'll eat tons of
+	 * kernel address space for nothing if the gfx card has alot of
+	 * memory (>= 128 MB isn't uncommon these days ...) */
+	if (vesafb_fix.smem_len > 16 * 1024 * 1024)
+		vesafb_fix.smem_len = 16 * 1024 * 1024;
+
 #ifndef __i386__
 	screen_info.vesapm_seg = 0;
 #endif

There used to be a vesafb problem with MTRRs when the framebuffer had an odd size: 2.5MB of RAM (my laptop has this).

It would create an MTRR for the first 0.5MB of the framebuffer, and then try to create another for the subsequent 2MB.

The latter failed because it's not suitably aligned - i.e. there was a problem in th logic which splits non-power-of-two regions.

Is that fixed these days?

Cheers,
-- Jamie

Better would be to use change_page_attr to manipulate PAT bits. We then wouldn't have to worry at all about alignment, running out of MTRRs, or collisions with other MTRRs.

Dave

Not all the MTRR using chips use PAT - but its certainly a start. The base algorithm for allocating MTRRs as efficiently as sanely possible is already in the kernel btw - or pretty close to it - its used by the Winchip code to cover RAM with out of order store.

Sure.

Does that support wierdo cases like Jamie's though?
I can't see how you can cover an not-a-powerof2 size area of memory without doing too little/too much. The winchip code was written with RAM in mind, which is always a power of 2 unless you boot with mem=fooMB

Dave

RAM is never power of two, a few bits always vanish off the ends. The trick is that you start at a power of 2 boundary then build up/down if you have to do power of two ranges