lkml.org 
[lkml]   [2008]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory vs. MMIO ordering, again
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..


\
 
 \ /
  Last update: 2008-12-24 22:19    [W:0.047 / U:0.628 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site