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

[will.deacon@arm.com (Will Deacon)]

On Tue, Jun 17, 2014 at 03:50:25PM +0100, Stuart Yoder wrote:
> > > I think for simple masters (i.e. those that have all their StreamIDs
> > > under control of one driver), then setting something during attach (or
> > > add?) based on the DT could work pretty well. The other case is when we
> > > have masters behind a bridge (such as a PCI RC). In this case, it might
> > > actually be better to ask the bridge for the IDs and let it sort out
> > the
> > > allocation itself. That would also move the RequesterID -> StreamID
> > > mapping out of the SMMU code.
> > >
> > > What do you think?
> > The PCI bus iommu group creation code would be part of the SMMU driver
> > (it is handled by other IOMMU drivers as well). My understanding is that
> > there would be one is to one correspondence between the requestor ID and
> > the iommu group. May be, we can have an API provided by the PCI bridge
> > (architecture specific) for setting the stream ID.
> 
> I think Will is suggesting something along those lines-- I think it's a
> question of where the streamID allocation happens.  You could
> either do something like the following in the SMMU driver when attaching
> a PCI device:
> 
>     id = alloc_stream_id(...);
>     pci_set_streamid(pci-dev, id);
> 
>     or
> 
>     id = pci_get_streamid(pci-dev);
> 
> ...i.e the PCI RC could allocate (from some TBD
> allocator) and set the stream ID itself.
> 
> Not sure how big a deal it is to extend PCI RC interfaces for 
> something like that.

I think both interfaces have their place; the latter for hotpluggable buses
and the former for static allocation (i.e. set once). The only way to see
how well it works is to try implementing it, I guess.

Will