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? -- 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
