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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
