Messages in this thread | | | Date | Sun, 27 Apr 2008 18:39:24 -0400 | From | Jeff Garzik <> | Subject | Re: [patch] x86, voyager: fix ioremap_nocache() |
| |
James Bottomley wrote: > Here's another piece of the x86 API that's designed to be cached. The > dma_declare_coherent_memory() usually represents behind bridge memory > that's fully participatory in the coherence model. > > Making it uncached damages the utility of this memory because doing > cacheline sized burst cycles when needed to it is far faster than > individual byte/word/quad writes. > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> > > --- > > diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c > index 388b113..df83ffd 100644 > --- a/arch/x86/kernel/pci-dma.c > +++ b/arch/x86/kernel/pci-dma.c > @@ -214,7 +214,7 @@ int dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr, > > /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN */ > > - mem_base = ioremap(bus_addr, size); > + mem_base = ioremap_cache(bus_addr, size); > if (!mem_base) > goto out;
Surely the change in semantics will find other places to creep out like this?
I would rather change drivers to use ioremap_nocache(), and leave the API as-is.
Isn't there Yet More Breakage in lib/iomap.c, given these new semantics?
if (flags & IORESOURCE_MEM) { if (flags & IORESOURCE_CACHEABLE) return ioremap(start, len); return ioremap_nocache(start, len); }
Any driver using pci_iomap() (libata, and others) is affected.
I disagree with this semantics change. A number of code places _and drivers_ GET IT RIGHT, and these are all broken now?
Jeff
| |