On Wed, Jun 26, 2013 at 12:42 PM, Will Deacon [off-list ref] wrote:

On Wed, Jun 26, 2013 at 05:19:48PM +0100, Stuart Yoder wrote:

quoted

On Wed, Jun 26, 2013 at 8:39 AM, Will Deacon [off-list ref] wrote:

quoted

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.

So, why don't we define which interrupt is which in this binding?
...e.g. "The first
interrupt specifier is for the configuration access fault interrupt, the second
interrupt specifier is for other global faults."

How else is software supposed to know which interrupt corresponds to what
event.

Thanks,
Stuart