[RFC PATCH v2 2/3] arm64: add IOMMU dma_ops

[robin.murphy@arm.com (Robin Murphy)]

On 09/03/15 20:09, Robin Murphy wrote:
[...]
>>> I think ideally you'd call dma_map_page when you first create the page
>>> table, dma_sync_single_for_device on any update, and dma_unmap_page when you
>>> tear it down, and you'd also use the appropriate DMA addresses everywhere
>>> instead of physical addresses.
>>
>> No.
>>
>> dma_map_page()			ownership changes CPU->DMA
>> dma_sync_single_for_cpu()	ownership changes DMA->CPU
>> dma_sync_single_for_device()	ownership changes CPU->DMA
>> dma_unmap_page()		ownership changes DMA->CPU
>>
>> It's invalid to miss out the pairing that give those ownership changes.
>
> Thanks for the clarification - the wording in DMA-API.txt rather implies
> that in the DMA_TO_DEVICE case you only have to sync the updated data
> /after/ writing it. For the sake of purely getting pages flushed, would
> it be more reasonable then to call dma_map_single() followed immediately
> by dma_unmap_single_attrs() with DMA_ATTR_SKIP_CPU_SYNC? Since we know
> the IOMMU can never write back to memory  (ones that can are a different
> issue) it would be nice to be able to skip the extra invalidations
> somehow, without too heinously abusing the API.

Scratch that, I'm being a massive idiot (again). Of course the actual 
invalidations will only happen if they need to, based on the DMA 
direction. The overhead of dma_sync_*_for_cpu() and dma_unmap() is then 
only a handful of function calls, which is probably an acceptable price 
to pay for making sure things work as correctly as possible.

>
> Robin.
>
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>