[PATCH 2/8] ARM: Implement read/write for ownership in the ARMv6 DMA cache ops

[Russell King - ARM Linux]

On Wed, May 12, 2010 at 02:55:39PM +0100, Catalin Marinas wrote:
> Drivers shouldn't call dma_inv_range if they have valid date in that
> buffer (that's why I removed the dma_inv_range call from
> dma_unmap_area).

That (removal of dma_inv_range) is the wrong approach - if drivers are
expecting data in the cache to be preserved over a dma_unmap_area() call,
they are buggy and need fixing.

However...

> > 2) CPU 0 is doing inv, the str write garbage which get to the DRAM
> > because of eviction and break the assumption that inv shouldn't change
> > the DRAM...
> 
> This may be the case but is there such situation?

This is why there's a problem - if we (rightfully) have dma_unmap_area()
call dma_inv_range, and dma_inv_range() corrupts the SDRAM, that's where
the bug is - dma_unmap_area() must not change the contents of SDRAM.

Aren't there CPUs which speculatively prefetch _and_ which don't have
broadcast cache ops?  If yes, then we can't use the "read/write to
gain ownership" approach - and since we can't use IPIs either, I think
we're sadly boxed in by hardware restrictions to the point of not being
able to run with DMA on these CPUs.