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

[Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> writes:

> On Thu, Aug 14, 2014 at 07:47:42AM +0100, Hiroshi Doyu wrote:
>> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> 
>> > +Multiple-master IOMMU:
>> > +----------------------
>> > +
>> > +       iommu {
>> > +               /* the specifier represents the ID of the master */
>> > +               #iommu-cells = <1>;
>> > +       };
>> > +
>> > +       master@1 {
>> > +               /* device has master ID 42 in the IOMMU */
>> > +               iommus = <&{/iommu} 42>;
>> > +       };
>> > +
>> > +       master@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.