| Message ID | 20221107175305.63975-2-prabhakar.mahadev-lad.rj@bp.renesas.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add IRQC support to RZ/G2UL SoC | expand |
On 07/11/2022 18:53, Prabhakar wrote: > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > identical to one found on the RZ/G2L SoC. No driver changes are > required as generic compatible string "renesas,rzg2l-irqc" will be > used as a fallback. > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > --- Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
Hi Geert, On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote: > > Hi Geert, > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > > > Hi Prabhakar, > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > used as a fallback. > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > Thanks for your patch! > > > > > --- > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > domain) -> RISCV INTC > > > > I think this difference is purely a software difference, and abstracted > > in DTS through the interrupt hierarchy. > > Does it have any impact on the bindings? > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > warranting separate compatible values. > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > Can you please elaborate? I may have missed something, but to me it > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > do you think it would make sense to add interrupt-names too? > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > register a handler for it). > Gentle ping. Cheers, Prabhakar
Hi Prabhakar, On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote: > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > <prabhakar.csengg@gmail.com> wrote: > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > <geert@linux-m68k.org> wrote: > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > > used as a fallback. > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > > domain) -> RISCV INTC > > > > > > I think this difference is purely a software difference, and abstracted > > > in DTS through the interrupt hierarchy. > > > Does it have any impact on the bindings? > > > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > > warranting separate compatible values. > > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > > > Can you please elaborate? I may have missed something, but to me it > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > > do you think it would make sense to add interrupt-names too? > Gentle ping. Thanks for the ping, I had missed you were waiting on input from me. Sorry for that... As there are three different groups of parent interrupts, adding interrupt-names makes sense. However, as this binding is already in active use since v6.1, you probably need to keep on supporting the ack of interrupt-names. Or do you think there are no real users yet, and we can drop support for that? > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > > register a handler for it). Do you mean you will need a fourth parent type for that? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Prabhakar, > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar > <prabhakar.csengg@gmail.com> wrote: > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > > <prabhakar.csengg@gmail.com> wrote: > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > > <geert@linux-m68k.org> wrote: > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > > > used as a fallback. > > > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > > > domain) -> RISCV INTC > > > > > > > > I think this difference is purely a software difference, and abstracted > > > > in DTS through the interrupt hierarchy. > > > > Does it have any impact on the bindings? > > > > > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > > > warranting separate compatible values. > > > > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > > > > > Can you please elaborate? I may have missed something, but to me it > > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > > > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > > > do you think it would make sense to add interrupt-names too? > > > Gentle ping. > > Thanks for the ping, I had missed you were waiting on input from me. > Sorry for that... > No worries. > As there are three different groups of parent interrupts, adding > interrupt-names makes sense. Ok. > However, as this binding is already in active use since v6.1, you > probably need to keep on supporting the > ack of interrupt-names. Or do you think there are no real users yet, > and we can drop support for that? > Sorry can you please elaborate on "ack of interrupt-names". So moving forward the driver will first check for interrupt-names property and if that exists it will map the IRQ0-7 and GPIO-TINIT interrupts (based on the names it will create a hierarchy domain) and for the NMI and BUS_ERR_INT we request the IRQ numbers and register the IRQ handler in IRQC driver itself. And for backward compatibility we parse the IRQ numbers based on indexes i.e. 0 = NMI, 1-8 = IRQ 0-7 and 9-41 GPIO TINT interrupts. > > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > > > register a handler for it). > > Do you mean you will need a fourth parent type for that? > No something like what we have for NMI we can add something similar below for bus error interrupts: interrupts = .... <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>; interrupt-names = ...., "bus-error-int"; As the registers to handle the NMI and BUS_ERR_INT are present on the IRQC block, the interrupt handler will have to be registered by the IRQC block itself by requesting the IRQ. So we will have to skip mapping of BUS_ERR_INT as we do for the NMI case. Does that make sense? Cheers, Prabhakar
Hi Prabhakar, On Mon, Dec 19, 2022 at 3:26 PM Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote: > On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar > > <prabhakar.csengg@gmail.com> wrote: > > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > > > <prabhakar.csengg@gmail.com> wrote: > > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > > > <geert@linux-m68k.org> wrote: > > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > > > > used as a fallback. > > > > > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > > > > domain) -> RISCV INTC > > > > > > > > > > I think this difference is purely a software difference, and abstracted > > > > > in DTS through the interrupt hierarchy. > > > > > Does it have any impact on the bindings? > > > > > > > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > > > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > > > > warranting separate compatible values. > > > > > > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > > > > > > > Can you please elaborate? I may have missed something, but to me it > > > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > > > > > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > > > > do you think it would make sense to add interrupt-names too? > > > > > Gentle ping. > > > > Thanks for the ping, I had missed you were waiting on input from me. > > Sorry for that... > > > No worries. > > > As there are three different groups of parent interrupts, adding > > interrupt-names makes sense. > Ok. > > > However, as this binding is already in active use since v6.1, you > > probably need to keep on supporting the > > ack of interrupt-names. Or do you think there are no real users yet, > > and we can drop support for that? > > > Sorry can you please elaborate on "ack of interrupt-names". Oops, s/ack/lack/. I.e. what you described below. > So moving forward the driver will first check for interrupt-names > property and if that exists it will map the IRQ0-7 and GPIO-TINIT > interrupts (based on the names it will create a hierarchy domain) and > for the NMI and BUS_ERR_INT we request the IRQ numbers and register > the IRQ handler in IRQC driver itself. > > And for backward compatibility we parse the IRQ numbers based on > indexes i.e. 0 = NMI, 1-8 = IRQ 0-7 and 9-41 GPIO TINT interrupts. Exactly. > > > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > > > > register a handler for it). > > > > Do you mean you will need a fourth parent type for that? > > > No something like what we have for NMI we can add something similar > below for bus error interrupts: > interrupts = .... > <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>; > interrupt-names = ...., > "bus-error-int"; Hence a fourth name? 1. legacy index 0 -> "nmi" 2. legacy indices 1-8 -> "irq%u" (0-7) 3. legacy indices 9-41 -> "tint%u" (0-31) 4. (not supported) -> "bus-error-int" (or "bus-err"?) > As the registers to handle the NMI and BUS_ERR_INT are present on the > IRQC block, the interrupt handler will have to be registered by the > IRQC block itself by requesting the IRQ. So we will have to skip > mapping of BUS_ERR_INT as we do for the NMI case. Does that make > sense? OK. BTW, that means RZG2L_NMI from <dt-bindings/interrupt-controller/irqc-rzg2l.h> will never be used? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, On Mon, Dec 19, 2022 at 2:47 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Prabhakar, > > On Mon, Dec 19, 2022 at 3:26 PM Lad, Prabhakar > <prabhakar.csengg@gmail.com> wrote: > > On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar > > > <prabhakar.csengg@gmail.com> wrote: > > > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > > > > <prabhakar.csengg@gmail.com> wrote: > > > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > > > > <geert@linux-m68k.org> wrote: > > > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > > > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > > > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > > > > > used as a fallback. > > > > > > > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > > > > > domain) -> RISCV INTC > > > > > > > > > > > > I think this difference is purely a software difference, and abstracted > > > > > > in DTS through the interrupt hierarchy. > > > > > > Does it have any impact on the bindings? > > > > > > > > > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > > > > > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > > > > > warranting separate compatible values. > > > > > > > > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > > > > > > > > > Can you please elaborate? I may have missed something, but to me it > > > > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > > > > > > > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > > > > > do you think it would make sense to add interrupt-names too? > > > > > > > Gentle ping. > > > > > > Thanks for the ping, I had missed you were waiting on input from me. > > > Sorry for that... > > > > > No worries. > > > > > As there are three different groups of parent interrupts, adding > > > interrupt-names makes sense. > > Ok. > > > > > However, as this binding is already in active use since v6.1, you > > > probably need to keep on supporting the > > > ack of interrupt-names. Or do you think there are no real users yet, > > > and we can drop support for that? > > > > > Sorry can you please elaborate on "ack of interrupt-names". > > Oops, s/ack/lack/. I.e. what you described below. > Got that. > > So moving forward the driver will first check for interrupt-names > > property and if that exists it will map the IRQ0-7 and GPIO-TINIT > > interrupts (based on the names it will create a hierarchy domain) and > > for the NMI and BUS_ERR_INT we request the IRQ numbers and register > > the IRQ handler in IRQC driver itself. > > > > And for backward compatibility we parse the IRQ numbers based on > > indexes i.e. 0 = NMI, 1-8 = IRQ 0-7 and 9-41 GPIO TINT interrupts. > > Exactly. > > > > > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > > > > > register a handler for it). > > > > > > Do you mean you will need a fourth parent type for that? > > > > > No something like what we have for NMI we can add something similar > > below for bus error interrupts: > > interrupts = .... > > <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>; > > interrupt-names = ...., > > "bus-error-int"; > > Hence a fourth name? > Agreed. > 1. legacy index 0 -> "nmi" > 2. legacy indices 1-8 -> "irq%u" (0-7) > 3. legacy indices 9-41 -> "tint%u" (0-31) > 4. (not supported) -> "bus-error-int" (or "bus-err"?) > "bus-err" I think based on previous experience ;) While I am at it I'll expand the interrupts property with descriptions. > > As the registers to handle the NMI and BUS_ERR_INT are present on the > > IRQC block, the interrupt handler will have to be registered by the > > IRQC block itself by requesting the IRQ. So we will have to skip > > mapping of BUS_ERR_INT as we do for the NMI case. Does that make > > sense? > > OK. > > BTW, that means RZG2L_NMI from <dt-bindings/interrupt-controller/irqc-rzg2l.h> > will never be used? > Agreed, that needs to be dropped. Cheers, Prabhakar
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml index 33b90e975e33..8f3678a82ba4 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml @@ -26,6 +26,7 @@ properties: compatible: items: - enum: + - renesas,r9a07g043u-irqc # RZ/G2UL - renesas,r9a07g044-irqc # RZ/G2{L,LC} - renesas,r9a07g054-irqc # RZ/V2L - const: renesas,rzg2l-irqc