Re: [PATCH] uvesafb,vesafb: create write-combining or write-back PAT entries
From: Paul Mundt <hidden>
Date: 2010-11-30 06:11:50
Also in:
lkml
On Sat, Nov 27, 2010 at 02:37:37PM +0100, Thomas Schlichter wrote:
quoted hunk ↗ jump to hunk
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c index 52ec095..5a34bc8 100644 --- a/drivers/video/uvesafb.c +++ b/drivers/video/uvesafb.c
...
- info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
+ uvesafb_init_mtrr(info);
+
+ switch (mtrr) {
+ case 1: /* uncachable */
+ info->screen_base = ioremap_nocache(info->fix.smem_start, info->fix.smem_len);
+ break;
+ case 2: /* write-back */
+ info->screen_base = ioremap_cache(info->fix.smem_start, info->fix.smem_len);
+ break;
+ case 3: /* write-combining */
+ info->screen_base = ioremap_wc(info->fix.smem_start, info->fix.smem_len);
+ break;
+ case 4: /* write-through */
+ default:
+ info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
+ break;
+ }
if (!info->screen_base) {
printk(KERN_ERRuvesafb presently has no special architecture dependencies, but ioremap_wc() is not as of yet a wholly generic interface. Some architectures that don't set ARCH_HAS_IOREMAP_WC get it by virtue of the asm-generic/iomap.h include, and most of the nommu architectures will stub it in via asm-generic/io.h, but this still leaves quite a long list of platforms that don't handle it at all. Your options at this point are either to establish ioremap_wc() as a generic API, and layer this patch on top of that, or rework uvesafb_init_mtrr() to do the actual broken-out remapping and rework it in to something like a uvesafb_remap(), where you bury the MTRR details under CONFIG_MTRR. While there's probably value in exposing ioremap_wc() as a generic interface, you're never going to hit any of the non-default ioremap() calls on platforms lacking MTRRs anyways, so special-casing it is ok.