[PATCH v2] documentation: iommu: add description of ARM System MMU binding

[Andreas Herrmann]

On Mon, May 13, 2013 at 05:58:46AM -0400, Will Deacon wrote:
> On Mon, May 13, 2013 at 10:50:20AM +0100, Andreas Herrmann wrote:
> > Hi Will,
> 
> Hi Andreas,
> 
> > so far, I thought, that this proposal is fine. After I have tried to
> > make use of the binding I have some points that might need further
> > disucssion.
> 
> Sure, although I've been using the binding without issues so it would be
> interesting to understand your use-case and why it's raising problems.
> 
> > Olav already asked (in another thread) how to model the mapping of
> > stream IDs to contexts for master devices that support multiple
> > contexts.  I doubt that this is fully covered yet.
> 
> Yeah, I've been meaning to reply to that. Given the way that the IOMMU API
> is structure in Linux, I don't think having multiple stream IDs per (struct)
> device, where each StreamID points at a different context (and therefore
> address space) makes much sense. It also doesn't solve the more general
> problem where StreamIDs for a device might have different SMMUs downstream.
> 
> To solve this, I think it is better to treat the device as having multiple
> struct device instances, and managing the mappings in the device driver.

Ok.

> For most devices, I'd expect a single context to be enough. This is
> certainly the case for device virtualisation at stage-2 and DMA at stage-1.

Yep, that's the usual case.
(Just thought what other scenarios there are.)

So the DT binding is for the most common (single-context) use case only.
(And everything else needs special device driver treatment.)

> > I also think that it is more useful to move the stream-id property to
> > the device node of a master device. (It's a characteristic of the
> > master device not of the SMMU.) Currently with multiple stream IDs per
> > master device you have repeated entries in the mmu-master property.
> 
> The problem with that approach is how to handle StreamID remastering. This
> can and will happen, so the StreamID for a device is actually a property of
> both the device *and* a particular point in the bus topology. Putting this
> information in the device nodes will drag topology information all over the
> place and I don't think it will make things clearer to read or easier to parse.

Ok, good point, didn't think about that.
And agreed, adding remastered StreamIDs as a property to a device node is odd.

> > But all that is needed is to point (once) to each mmu-master in the
> > SMMU device node. Then you should be able to look up the corresponding
> > stream IDs in the device node for each mmu-master.
> 
> Again, you also need to tie in topology information if you go down this
> route.


Thanks,
Andreas