Nishanth Peethambaran nishanth.p@gmail.com wrote @ Thu, 20 Jun 2013 10:55:32 +0200:
Thinking again on it, I feel the translation of dma-attr should happen when dma-mapping code makes calls to " iommu mapping" API. "iommu mapping" API which does iova management and make iommu API calls could be taken out from dma-mapping.c, for which I see discussion already happening for arm64.
According to the discussion ARM64:dma-mapping, I got an implression that IOVA management part in ARM:dma-mapping API would be a new common module(ie: /lib/iommu-helper.c), but still IOMMU API itself would reamin as primitive as what they are.
+--------------------------------- | DMA mapping API | +----------------- +--------------+-----------+ | DMA mapping API($ARCH) | IOMMU API | IOVA MGT | +------------------ +--------------+-----------+ |IOMMU API(H/W)| +--------------+ | IOMMU H/W | +--------------+
If devices allocate via dma-mapping API, physical mem allocation, iova allocation and iommu mapping happens internally. Devices may allocate physical memory using any allocator (say ION including carveout area), use "iommu mapping" API which will do iova allocation and iommu mapping. The prot flags could be useful in this case as well - not sure whether we would need dma-attrs here.
I haven't followed ION recently, but can't ION backed by DMA mapping API instead of using IOMMU API directly?