Re: [PATCH] uvesafb,vesafb: create write-combining or write-back PAT entries

[Thomas Schlichter <thomas.schlichter@web.de>]

[-- Attachment #1: Type: Text/Plain, Size: 1705 bytes --]

Sorry for answering this late, unfortunately I was quite busy with my daily 
work...

Am Dienstag 30 November 2010, um 07:10:51 schrieb Paul Mundt:
> 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.

Thank you for finding that problem and showing possibilities for fixing it. I 
prepared 3 patches, where the first essentially is my old patch with special-
casing via ifdef CONFIG_X86. The second patch establishes ioremap_cache() and 
ioremap_wc() for all architectures, and the third patch removed the special-
casing from uvesafb.

So the first patch can stand on its own and hopefully can be merged upstream. 
The third patch needs the second one, which may be merged for unifying 
purposes. But as these are mor cleanup-patches, they are not that important 
for me.

Best regards,
Thomas Schlichter

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]