Hi Geert, On Mon, Dec 19, 2022 at 2:47 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Hi Prabhakar, > > On Mon, Dec 19, 2022 at 3:26 PM Lad, Prabhakar > <prabhakar.csengg@xxxxxxxxx> wrote: > > On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar > > > <prabhakar.csengg@xxxxxxxxx> wrote: > > > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > > > > <prabhakar.csengg@xxxxxxxxx> wrote: > > > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > > > > <geert@xxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote: > > > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > > > > > > > > > > > > > > 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@xxxxxxxxxxxxxx> > > > > > > > > > > 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
