On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: > Right, we indeed need two levels of API, one for drivers such as remoteproc > that need direct control of the IOMMU, and one for drivers that only need to > map buffers without any additional requirement. In the second case the drivers > should ideally use the DMA mapping API not even be aware that an IOMMU is > present. This would require moving the ARM mapping allocation out of the > client driver. These two levels exist in the form of the DMA-API and the IOMMU-API. In fact, the IOMMU-API was created to provide a way to drivers to specifiy the IOVA->PHYS mappings on its own. > The IOMMU core or the IOMMU driver will need to know whether the driver > expects to control the IOMMU directly or to have it managed transparently. As > this is a software configuration I don't think the information belongs to DT. > The question is, how should this information be conveyed ? The way this works on x86 is that a device driver can use the DMA-API per default. If it wants to use the IOMMU-API it has to allocate a domain and add the device it handles to this domain (it can't use DMA-API anymore then). Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
