Messages in this thread | | | Subject | Re: [PATCH 3/9] dt-bindings: interrupt-controller: arm, gic-v3: Describe ESPI range support | From | Lokesh Vutla <> | Date | Tue, 23 Jul 2019 19:05:01 +0530 |
| |
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. >
| |