Re: [PATCH][RFC] asm-generic:remove calling flush_write_buffers()in dma_sync_*_for_cpu

[Russell King - ARM Linux]

On Tue, Jul 07, 2009 at 09:43:37PM +0800, Ming Lei wrote:
> 2009/7/7 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>:
> > On Tue, Jul 07, 2009 at 09:54:20AM +0800, Ming Lei wrote:
> >> 2009/6/30 Arnd Bergmann <arnd@xxxxxxxx>:
> >> > On Tuesday 30 June 2009, Alan Cox wrote:
> >> > Well, not even that. dma-mapping-common.h only makes sense on architectures
> >> > that have multiple dma-mapping implementations (parisc, mips, arm, powerpc,
> >>
> >> It seems that there is only one dma-mmaping implementation on ARM, doesn't it?
> >> Is it necessary that using dma-mapping-common.h on ARM?
> >
> > ARM has two (normal, and dma bounce), and in the long run we need to do
> 
> OK, Can we use dma-mapping-common.h on ARM?

No.

> > cache handling on unmap as well as map due to CPU speculative fetches.
> 
> IMHO, it seems we can fix this problem now.
> 
> For DMA_TO_DEVICE transfer, clean cache in dma map, but does nothing in
> dma unmap;
> 
> For  DMA_FROM_DEVICE, we may do nothing in dma map, but invaliate cache
> in dma unmap.

No.  If there are dirty lines, they can be written back, overwriting the
data which has been DMA'd there.

Basically, with speculative prefetching, we need to:

- for DMA_TO_DEVICE, clean the cache in the DMA map and do nothing on DMA unmap
- for DMA_FROM_DEVICE, invalidate the cache on DMA map and again on DMA unmap

Moreover, this isn't going to be trivial.  In order to do these cache
operations, we need the virtual address.  However, the unmap APIs aren't
given this information (though dma_to_virt() will do what's required for
the dma_unmap_single case.)

dma_unmap_page() on the other hand, we don't have any API existing to
turn a DMA address back into a page struct...

If only we had an architecture specific struct to contain whatever
information needs to be carried from map to unmap...
--
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/