On Sat, Nov 27, 2010 at 02:37:37PM +0100, Thomas Schlichter wrote:
> 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_ERR
uvesafb 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
