Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH] ioremap_cached() | Date | Thu, 30 Mar 2006 21:50:05 +0200 |
| |
On Thursday 30 March 2006 21:34, Matthew Wilcox wrote: > On Thu, Mar 30, 2006 at 08:27:53PM +0200, Andi Kleen wrote: > > Matthew Wilcox <matthew@wil.cx> writes: > > > > > We currently have three ways for getting access to device memory -- > > > ioremap(), ioremap_nocache() and pci_iomap(). 99% of the callers of > > > ioremap() are doing it to access device registers, and really, really > > > want to use ioremap_nocache() instead. I presume nobody notices on PCs > > > because they have write-through caches, but it ought to trip up people > > > trying to flush writes. > > > > Actually MTRRs take care of that on x86. > > So essentially on x86 ioremap() for devices is already ioremap_uncached() > > And ioremap on memory is cached. > > > > That's nice and simple semantics that other platforms can emulate too. > > Doing things differently will just cause pain for the other platforms > > when they have to fix up drivers all the time. > > That doesn't make any sense. What's the point of ioremap_nocache() if > ioremap() does magic things that make things uncached?
In theory ioremap_nocache would force uncached even if there is no MTRR and is better/clearer.
But on x86 there normally is, so lots of code gets it wrong.
My point is just that forcing a semantics that's not enforced on x86 would be a uphill battle for everybody else. Probably not a good idea. Better fake x86.
> And who says > you're allowed to ioremap() memory anyway?
Why not? There are cases when it's needed.
> > It all works fine until someone wants WC too. I would rather add a > > ioremap_wc(), that would be more useful. > > ioremap_wc() sounds like a good idea.
It's unfortunately tricky to get it fully right on x86. The issue is to have a good way avoid illegal cache aliases. There were some attempts, but so far they never were polished up from the initial prototypes.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |