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@xxxxxxxxxxxxxx> wrote: > > > > Hi Marc, > > > > .org>; Phil Edworthy > > > <phil.edworthy@xxxxxxxxxxx> > > > 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@xxxxxxxxxxxxxx> 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
