Not "memory-mapped devices" in general: the accesses have side effects.
But for things like framebuffers you are right.
> o Scattered writes/reads, i.e., a page appart should go
> to the physical RAM. I have never seen it do differently.
This depends on the number of "ways" of the cache, and how it is mapped.
E.g. in most if not all x86s, accesses a page appart do map to the same
cache line address, so there is potential for one access to flush the
cached contents of another. However, as there are 2 or more ways (4 on
P5MMX for example), the cache can hold data for several lines at the
same line address, and the flush is not guaranteed.
AFAIK you cannot rely on this for any kind of write-allocating cache
unless you know the structure of the cache.
The behaviour of writes depends on the cache's write policy. Most
modern x86 processors use write-allocate unless told otherwise, which
means that even isolated writes will cause the entire cache line to be
read in and then modified locally.
On processors that do write-back, your read-modify-write instruction
causes the line to be read in anyway at first, and then modified
locally.
It is only write-through caches such as the 486s (I think; my memory is
not strong on this), where the writes will always go outside the
memory. The read test later still fetches from the local cache though.
To finish, the L2 cache is often a write-back/write-allocate cache even
if the processor cache is not. So still physical memory is not tested.
> If it didn't, you would not be able to use memory-mapped
> I/O because the CPU would read its cache instead of physical
> RAM.
Memory-mapped I/O works because:
- ioremap() maps the memory and marks the pages uncacheable.
E.g. on an x86, the PCD (page cache disable) bit is set.
- For some processors, the CPU bus protocols allow the processor to
be informed of memory locations it should not cache.
This does not help with memory detection though, because a specific
address range may be hardwired as "memory -- cache permitted", and
the physical memory may be a subrange of that.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/