RE: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain to handle GPIO interrupt

[Biju Das <biju.das.jz@bp.renesas.com>]

Hi Marc,

> Subject: Re: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ
> domain to handle GPIO interrupt
> 
> On Mon, 16 May 2022 09:33:03 +0100,
> Biju Das <biju.das.jz@bp.renesas.com> wrote:
> >
> > Hi Marc,
> >
> > .org>; Phil Edworthy
> > > <phil.edworthy@renesas.com>
> > > Subject: Re: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ
> > > domain to handle GPIO interrupt
> > >
> > > On Mon, 16 May 2022 08:20:47 +0100,
> > > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > >
> > > > > >
> > > > > > I believe from interrupt statistics point of view, cat
> > > > > > /proc/interrupts should report actual gpioint number (0->122)
> > > > > > corresponding to pin index for SW1, SW2 and SW3 ??
> > > > >
> > > > > No. There is no need for such userspace-visible behaviour.
> > > > > Userspace has no business tracking those. The required
> > > > > information is in debugfs, and that more than enough.
> > > >
> > > > Ok, So far I used cat /proc/interrupts for debugging, since I
> > > > don't need to enable DEBUG config for Enabling Debugfs for irq.
> > > > This Debugfs irq is new info to me.
> > > >
> > > > Our hardware manual has below info for usb-phy irq
> > > > 2H0_OBINT	126(InterruptID)	SPI 94	IRQ 94	Level
> > > >
> > > > cat /proc/interrupts matches with GICV3 Interrupt ID/ type in the
> > > > HW
> > > manual
> > > > 113:          0          0     GICv3 126 Level     11c50200.usb-phy
> > > >
> > > > Debugfs is also showing similar info like hwirq and interrupt type.
> > > > But I don't know which field corresponds to number of interrupts?
> > > >
> > > > root@smarc-rzg2l:~# cat /sys/kernel/debug/irq/irqs/113
> > > > handler:  handle_fasteoi_irq
> > > > device:   (null)
> > > > status:   0x00000104
> > > > istate:   0x00000000
> > > > ddepth:   0
> > > > wdepth:   0
> > > > dstate:   0x13402204
> > > >             IRQ_TYPE_LEVEL_HIGH
> > > >             IRQD_LEVEL
> > > >             IRQD_ACTIVATED
> > > >             IRQD_IRQ_STARTED
> > > >             IRQD_SINGLE_TARGET
> > > >             IRQD_DEFAULT_TRIGGER_SET
> > > >             IRQD_HANDLE_ENFORCE_IRQCTX
> > > > node:     0
> > > > affinity: 0-1
> > > > effectiv: 0
> > > > domain:  :soc:interrupt-controller@11900000-1
> > > >  hwirq:   0x7e
> > >
> > > 0x7e = 126 = 94 - 32 -> SPI94.
> > >
> > > What else do you need?
> >
> > OK, similar to GIC, I thought for gpio interrupts,
> 
> Err. This *IS* the GIC.

Yes, tint0-31(IA55 driver) is connected to the GIC which is backend
On the frontend(Pincontrol driver) where we have 123 interrupts (gpioint0-122) is mapped to tint0_31.
So parent of a particular gpio interrupt can be changed during insmod/rmmod operation.

> 
> > The  hwirq should match with gpiointN  mentioned in hwmanual. That is
> all.
> 
> There is no such need.
> 
> hwirq is whatever the driver decides it is, and userspace can't rely on it
> one way or another. If the driver author decides that it is more
> convenient to number hwirqs backwards, that's absolutely fine. If you are
> debugging, you have access to the driver code, the DT, and all the debugfs
> information. You can trace things back and forth as you please.

OK agreed.

Regards,
Biju