[PATCH 7/9] documentation: iommu: add description of ARM System MMU binding

[Will Deacon]

On Wed, Jun 26, 2013 at 05:19:48PM +0100, Stuart Yoder wrote:
> On Wed, Jun 26, 2013 at 8:39 AM, Will Deacon <will.deacon at arm.com> wrote:
> > I'd suggest looking at the driver I posted to get a gist of how the parsing
> > code works, but suffice to say that we describe both the number of
> > interrupts and the actual interrupt numbers here.
> 
> I understand that the number of interrupts and actual interrupt numbers
> are described here, but was referring to the _meaning_ of the interrupt
> numbers.   A binding for a device with 2 interrupts, a TX and RX would
> normally identify which interrupt specifier is for TX and which is for RX.
> 
> Based on your code, the 2 global interrupts seem to be the secure
> and non-secure fault interrupts...which your driver does not differentiate.
> However, the device tree is describing hardware and  you can't assume
> that all drivers don't care which is which.

Currently, the driver only works when Linux is running as non-secure, which is
becoming more and more common since it is required to be able to make use of
hyp mode.

There are actually two global interrupts for SMMUv1 and SMMUv2, which
correspond to configuration faults and `other' global faults.

> If there are other interrupts added in the future like the performance interrupt
> the definition could be expanded to add that.

PMU interrupts would like have a separate property, since the PMU would be
driven by a largely independent piece of code.

> But a question.... why do you need the #global-interrupts property
> at all?   Is the number of "global" interrupts really implementation dependent?
> Does't a specific compatible string imply the number of interrupts that there
> actually are?

Integrators have a nasty habit of ORing interrupts together or not wiring
them at all and I don't want to be caught out by that.

> > What bus hierarchy? If I have two SMMU device nodes, how do I infer any
> > topological information without an explicit linkage?
> 
> I really don't know anything about SMMU chaining, but am inferring what
> this might look like.   Does the "child" SMMU look just like another
> mmu-master to the parent?   If so, why not just use the mmu-masters
> property to establish the relationship.

No, the child SMMU does not look like a master. It can remaster upstream
StreamIDs, for example.

Will