Re: [PATCH RFC 1/5] dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Document RZ/G2UL SoC

[Geert Uytterhoeven]

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.

> 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@xxxxxxxxxxxxxx

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