On 10/25/2013 07:20 AM, Will Deacon wrote:

On Fri, Oct 25, 2013 at 09:22:02AM +0100, Hiroshi Doyu wrote:

quoted

Thierry Reding [off-list ref] wrote @ Fri, 25 Oct 2013 09:56:55 +0200:

quoted

I suspect that there will be enough differences between the various
IOMMU implementations that we won't be able to have a unified binding
(especially for how to associate devices with a particular virtual
address space), but perhaps that could be solved with something like an
.of_xlate() that IOMMU drivers implement, much like we've done with most
other subsystems too.

The binding for Tegra's IOMMU currently only uses the HW IDs (or a mask)
to put a device into a given address space, but I think that could be
easily extended to something like:

	memory-clients = <&iommu MASK>;

Or similar. If other information is required, we could encode that into
a multi-cell specifier. Perhaps we could even leave away the phandle
since typically there will only be a single IOMMU in the system?

Does that sound reasonable? Hiroshi is much more familiar with IOMMUs,
so I'd like to get his opinion on the above as well.

I think that the above may be possible, but I'd like to listen from
other IOMMU SOC maintainers.

A brief explanation for "memory-clients":

In tegra, every H/W has its own memory-client ID, and it can be
associated to any address spaces. The above "memory-cilents" is used
to indicate which ID a device has in DT. If the other SOC IOMMUs need
this kind of "memory-clients", this would be standarized. Any comment?

At least arm-smmu seems to have the following. multiple IOMMUs can be
handled with this.


- smmu-parent   : When multiple SMMUs are chained together, this
                  property can be used to provide a phandle to the
                  parent SMMU (that is the next SMMU on the path going
                  from the mmu-masters towards memory) node for this
                  SMMU.

This property is for the case when IOMMUs are connected in series, which is
fairly horrendous. However, it is extremely common to have multiple IOMMU
instances within an Soc (Exynos SoCs have one IOMMU per device iirc), so
that certainly needs to be handled.

That property sounds a bit scary; is the value a single parent IOMMU?
What if an IOMMU splits its requests between two different parent IOMMUs
based on some property of the request. I hope smmu-parent isn't going to
get us into another interrupts -vs- interrupts-extended situation.

(/me checks the documentation of that property)

I suppose smmu-parent is documented in a device-specific binding rather
than as a generic property, although there's no vendor-prefix on the
property name:-(, so we havne't cornered ourselves too much here; any
IOMMU device which actually has multiple parents can always define its
own custom property to represent that.