On Fri, Aug 15, 2014 at 01:29:41PM +0100, Hiroshi Doyu wrote:
> Will Deacon <will.deacon@xxxxxxx> writes:
> > 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".
The mapping should be done as part of the ->add_device callback, at the same
time as the iommu_group initialisation.
> 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?
No, I still don't think this is quite right. The SMMU deals with StreamIDs.
End of story. However, for a hotpluggable bus, you may need to determine
that StreamID from another dynamic ID. In the case of PCI, you can
dynamically find the RequesterID, then we'd just have an offset in the DT
node for the PCI host controller that describes how that maps to the StreamID.
So actually, we need to treat host controllers differently from end-points
in the binding, which would allow us to describe these transformations.
Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
