| Message ID | 20190723104437.154403-4-maz@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | irqchip/gic-v3: Add support for GICv3.1 extended PPI/SPI ranges | expand |
On 23/07/19 4:14 PM, Marc Zyngier wrote: > GICv3.1 introduces support for new interrupt ranges, one of them being > the Extended SPI range (ESPI). The DT binding is extended to deal with > it as a new interrupt class. > > Signed-off-by: Marc Zyngier <maz@kernel.org> > --- > .../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml > index c34df35a25fc..98a3ecda8e07 100644 > --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml > +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml > @@ -44,11 +44,12 @@ properties: > be at least 4. > > The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI > - interrupts. Other values are reserved for future use. > + interrupts, 2 for interrupts in the Extended SPI range. Other values > + are reserved for future use. Any reason why hardware did not consider extending SPIs from 1020:2043? This way only EPPI would have been introduced. Just a thought. Either ways, just to be consistent with hardware numbering can ESPI range be 3 and EPPI range be 2? Thanks and regards, Lokesh > > The 2nd cell contains the interrupt number for the interrupt type. > SPI interrupts are in the range [0-987]. PPI interrupts are in the > - range [0-15]. > + range [0-15]. Extented SPI interrupts are in the range [0-1023]. > > The 3rd cell is the flags, encoded as follows: > bits[3:0] trigger type and level flags. >
On 23/07/2019 13:59, Lokesh Vutla wrote: > > > On 23/07/19 4:14 PM, Marc Zyngier wrote: >> GICv3.1 introduces support for new interrupt ranges, one of them being >> the Extended SPI range (ESPI). The DT binding is extended to deal with >> it as a new interrupt class. >> >> Signed-off-by: Marc Zyngier <maz@kernel.org> >> --- >> .../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml >> index c34df35a25fc..98a3ecda8e07 100644 >> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml >> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml >> @@ -44,11 +44,12 @@ properties: >> be at least 4. >> >> The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI >> - interrupts. Other values are reserved for future use. >> + interrupts, 2 for interrupts in the Extended SPI range. Other values >> + are reserved for future use. > > Any reason why hardware did not consider extending SPIs from 1020:2043? This way > only EPPI would have been introduced. Just a thought. First, 1020-1023 is the special INTID range. You can't have anything else there. Then, making the range contiguous could imply that the range is also contiguous in the register space, which isn't possible (note that the EPPI range does it the other way around -- it is discontinuous in the INTID space, and yet continuous in the register space). Finally, the decision to push the numbering out towards the LPI range allows the ESPI space to be grown easily up to 4k. But frankly, none of that really matters. They are just numbers. > Either ways, just to be consistent with hardware numbering can ESPI range be 3 > and EPPI range be 2? Well, the way I see it is that it is more logical for the binding itself. We already have 0 for SPIs and 1 for PPIs, despite PPIs being before SPIs in the INTID space. Thanks, M.
On 23/07/19 6:45 PM, Marc Zyngier wrote: > On 23/07/2019 13:59, Lokesh Vutla wrote: >> >> >> On 23/07/19 4:14 PM, Marc Zyngier wrote: >>> GICv3.1 introduces support for new interrupt ranges, one of them being >>> the Extended SPI range (ESPI). The DT binding is extended to deal with >>> it as a new interrupt class. >>> >>> Signed-off-by: Marc Zyngier <maz@kernel.org> >>> --- >>> .../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++-- >>> 1 file changed, 3 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml >>> index c34df35a25fc..98a3ecda8e07 100644 >>> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml >>> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml >>> @@ -44,11 +44,12 @@ properties: >>> be at least 4. >>> >>> The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI >>> - interrupts. Other values are reserved for future use. >>> + interrupts, 2 for interrupts in the Extended SPI range. Other values >>> + are reserved for future use. >> >> Any reason why hardware did not consider extending SPIs from 1020:2043? This way >> only EPPI would have been introduced. Just a thought. > > First, 1020-1023 is the special INTID range. You can't have anything > else there. > > Then, making the range contiguous could imply that the range is also > contiguous in the register space, which isn't possible (note that the > EPPI range does it the other way around -- it is discontinuous in the > INTID space, and yet continuous in the register space). > > Finally, the decision to push the numbering out towards the LPI range > allows the ESPI space to be grown easily up to 4k. okay, got it. > > But frankly, none of that really matters. They are just numbers. > >> Either ways, just to be consistent with hardware numbering can ESPI range be 3 >> and EPPI range be 2? > > Well, the way I see it is that it is more logical for the binding > itself. We already have 0 for SPIs and 1 for PPIs, despite PPIs being > before SPIs in the INTID space. Agreed. Patch looks good to me. FWIW: Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Thanks and regards, Lokesh > > Thanks, > > M. >
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index c34df35a25fc..98a3ecda8e07 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -44,11 +44,12 @@ properties: be at least 4. The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI - interrupts. Other values are reserved for future use. + interrupts, 2 for interrupts in the Extended SPI range. Other values + are reserved for future use. The 2nd cell contains the interrupt number for the interrupt type. SPI interrupts are in the range [0-987]. PPI interrupts are in the - range [0-15]. + range [0-15]. Extented SPI interrupts are in the range [0-1023]. The 3rd cell is the flags, encoded as follows: bits[3:0] trigger type and level flags.
GICv3.1 introduces support for new interrupt ranges, one of them being the Extended SPI range (ESPI). The DT binding is extended to deal with it as a new interrupt class. Signed-off-by: Marc Zyngier <maz@kernel.org> --- .../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)