Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Tuesday 29 April 2014 13:07:54 Grant Grundler wrote:
> On Tue, Apr 29, 2014 at 11:16 AM, Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org> wrote:
> ...
> > An IOMMU is really a specialised bridge
> 
> Is a GART a bridge?
> 
> IOMMUs can provide three basic functions:
> 1) remap address space to reach phys mem ranges that the device is
> otherwise not capable of accessing (classic 32-bit DMA to reach 64-bit
> Phys address)
> 
> 2) implement scatter-gather (page level granularity) so the device
> doesn't have to
> 
> 3) provide some level of system protection against "rogue" DMA by
> forcing everything through a DMA mapping interface and faulting when
> encountering unmapped DMA transactions.

[ 4) provide isolation between multiple contexts, typically for purposes
     of virtualization]

> I summarize IOMMUs as: "participate in the routing of MMIO
> transactions in the system fabric."
> In this sense, IOMMUs are sort of a bridge. Defining what kind of
> routing they can do (coalesce transactions? remapping MMIO domains?)
> and which address ranges they route would describe most of that
> functionality.
> 
> This "remapping" of MMIO transaction is also usually asymmetric.
> Meaning routing of "downstream" transactions *might* be completely
> different than the routing + remapping of transactions heading
> upstream. DMA mappings services are designed to handle only the
> transactions generated (aka "mastered") by a downstream device.

For the purposes of the DT binding, we have a 'ranges' property
that defines the downstream translation (CPU-to-MMIO) and a
'dma-ranges' property for the opposite address translation
(device-to-memory).

> >, so it may be cleaner to describe
> > an IOMMU using a real bus node in the DT, if we also define a way to make
> > master/slave linkages explicit where it matters.
> 
> "where it matters" is a bit vague.  Is the goal to just enable DMA
> mapping services to "do the right thing" for a device that can
> generate DMA?

Yes. It's very complicated unfortunately, because we have to be
able to deal with arbitrary combinations of a lot of oddball cases
that can show up in random SoCs:

- device can only do DMA to a limited address range
- DMA is noncoherent and needs manual cache management
- DMA address is at an offset from physical address
- some devices have an IOMMU
- some IOMMUs are shared between devices
- some devices with IOMMU can have multiple simultaneous contexts
- a device may access some memory directly and some other memory through IOMMU
- a device may have DMA access to a bus that is invisible to the CPU
- DMA on some device is only coherent if the IOMMU is enabled
- DMA on some device is only coherent if the IOMMU is disabled
- the IOVA range to an IOMMU is device dependent

> > I've been hacking around some proposals on these areas which are a bit
> > different from the approach suggested here -- I'll try to summarise some
> > of it intelligibly and post something tomorrow so that we can discuss.
> 
> Are you planning on consolidating Documentation/devicetree/bindings/iommu/ ?
> Do you care about Documentation/Intel-IOMMU.txt?

I think we can ignore the Intel-IOMMU because that is specialized on PCI
devices, which we don't normally represent in DT. It is also a special
case because the Intel IOMMU is a single-instance device. If it's present
and enabled, it will be used by every device. The case we do need to describe
is when we don't know which IOMMU is used for which master, or how to
configure it.

	Arnd