Re: Memory vs. MMIO ordering, again

[Robert Hancock]

Alan Cox wrote:
> > MMIO accesses may, in effect, overtake accesses to cached memory that 
> > were emitted earlier. A memory barrier isn't sufficient in such a case, 
> > but rather the cache must be flushed between the cached memory write and 
> > the MMIO access if the two are in any way dependent."
> >
> > This seems like BS to me.. Flush the cache? How is a driver supposed to 
> > know how to do that? Furthermore, why should it need to worry about this 
> >   kind of detail? This seems wrong or at least a low-level detail that 
> > normal code should not have to be concerned with.
>
> There isn't really much choice in the matter. However if you are using
> the normal pci_map_ and pci_alloc_coherent functions then those have your
> cache management built into them and all you have to watch is compiler
> funnies.

What that documentation is suggesting is that MMIO writes to uncached 
memory (what the normal mapping functions will give you) can pass 
previous writes to cached memory. It doesn't indicate how this is to be 
avoided, however.

The arch that was being discussed in that 2006 discussion was PPC, but 
it appears that it's been changed to ensure that writeX, etc. will 
provide the expected ordering (commit 
f007cacffc8870702a1473d83ba5e4922d54e17c). I'm not sure what 
architecture the author of those paragraphs in 
Documentation/memory-barriers.txt had in mind, though. CCing David 
Howells as he apparently wrote them..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/