[PATCH v5] devicetree: Add generic IOMMU device tree bindings

Hi Will,

-----Original Message-----
From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
bounces at lists.linux-foundation.org] On Behalf Of Will Deacon
Sent: Friday, August 15, 2014 5:21 PM
To: Hiroshi Doyu
Cc: Mark Rutland; devicetree at vger.kernel.org; Stephen Warren; Arnd
Bergmann; Rob Herring; iommu at lists.linux-foundation.org; Thierry Reding;
linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

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. 

I don't completely agree with this. In case of MMU-500  don't we have the "TBUID + device assigned stream ID" representing the stream ID for matching at the TCU? In case of our platform, we have hot pluggable device objects comprising of devices connected to different TBUs. We have a requirement to use a single stream ID for all the distributed objects. We will have to use the stream ID masking capability to mask out the TBU ID.

-Varun