On Thursday 20 June 2013, Hiroshi Doyu wrote: > Arnd Bergmann <arnd@xxxxxxxx> wrote @ Thu, 20 Jun 2013 12:13:13 +0200: > > > On Thursday 20 June 2013, Hiroshi Doyu wrote: > > > > 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? > > > > For a GPU with an IOMMU, you typically want per-process IOMMU contexts, > > which are only available when using the IOMMU API directly, as the > > dma-mapping abstraction uses only one context for kernel space. > > Yes, we had some experiment for switching IOMMU context with DMA > mapping API. We needed to add some new DMA mapping API, and didn't > look so nice at that time. What do you think to introduce multiple > context or switching context in dma-mapping abstruction? My feeling is that drivers with the need for multiple contexts are better off using the iommu API, since that is what it was made for. The dma-mapping abstraction really tries to hide the bus address assignment, while users with multiple contexts typically also want to control the bus addresses. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
