Will Deacon [off-list ref] writes:

On Thu, Aug 14, 2014 at 07:47:42AM +0100, Hiroshi Doyu wrote:

quoted

Thierry Reding [off-list ref] writes:

quoted

+Multiple-master IOMMU:
+----------------------
+
+       iommu {
+               /* the specifier represents the ID of the master */
+               #iommu-cells = <1>;
+       };
+
+       master at 1 {
+               /* device has master ID 42 in the IOMMU */
+               iommus = <&{/iommu} 42>;
+       };
+
+       master at 2 {
+               /* device has master IDs 23 and 24 in the IOMMU */
+               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
+       };

I think that this "master ID" will be parsed in IOMMU driver. For
example, ARM,SMMU expects "streamID" as "master ID", right?

If a SoC has a feature to configure to assign streamID to devices at
runtime, "streamID" is not equal to "master ID".

  iommus = <&{/smmu} "soc specific master ID">;

"soc master ID" needs to be translated into "streamID" by SoC SW. It
seems that ARM,SMMU kernel driver doesn't expect this kind of ID
translation. If ARM,SMMU kernel driver is used as is, "soc master ID"
would be incompatible? ARM,SMMU needs such translation before
parsing. Is this my understanding right?

If so I think that this master ID configuration/translation may be quite
reasonable requirment for SoC using ARM,SMMU.

Can we consider this ID translation within ARM,SMMU compatibility?

IOW, is it possible to implement some SoC specific hook for ID
translation/configuration in ARM,SMMU kernel driver?

I think there's some confusion here. The ARM architected SMMU does not
perform any StreamID translation -- it sees an incoming ID and uses that to
lookup a set of translation tables. However, for hotpluggable buses (e.g.
PCI), we need a way to communicate the StreamIDs for a newly discovered
device to the SMMU. I expect that this would be described as a translation
from another ID (e.g. requester id for PCI), so *that* is where the
translation occurs.

This translation can be described as a simple base + offset calculation,
e.g. StreamID = RequesterID + offset. Ideally, you'd have one offset per
host controller (and described in the host controller DT node), but you
could also imagine building tables where each RequesterID maps to a
different StreamID.

The final thing to mention is that some SoCs may have device hotplug
architectures that aren't like PCIe, so we may well need glue code there to
`allocate' StreamIDs from a fixed portion of the numberspace.

Ok, I can assume that, when parsing generic IOMMU binding, SoC specific
callback could be called from ARM,SMMU driver to assign allocated
"StreamIDs" to thier "RequesterIDs".

IOW, IOMMU generic binding for ARM,SMMU can have RequresterID instead of
StreamID.

  Not:
  	iommus = <&{/arm-smmu} "StreamID">;
  
  Instead, can be:
  	iommus = <&{/arm-smmu} "RequresterID">;

If I extend the above, even ARM,SMMU driver could have any number of
params, which SoC requires with keeping "arm,mmu-*" compatibility?

  	iommus = <&{/arm-msmmu} param1 param2 param3 param4 .....>;

How to parse params depends on SoC. Parsing params is done at SoC
callback, right?

We don't need to solve all of these problems in one go, but the base +
offset code will certainly be useful; not just for the SMMU but also for
the GIC (where we have DeviceIDs). Mark Rutland is looking at this.

Any pointer would be really appreciated.