Thread (1 message) 1 message, 1 author, 2022-05-16

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

From: Biju Das <biju.das.jz@bp.renesas.com>
Date: 2022-05-16 08:33:14
Also in: linux-gpio, linux-renesas-soc, lkml

Hi Marc,

.org>; Phil Edworthy
[off-list ref]
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 [off-list ref] wrote:
quoted
quoted
quoted
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
quoted
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,

The  hwirq should match with gpiointN  mentioned in hwmanual. That is all.
Any way it is minor thing, it may be not at all needed. Please ignore this.

Eg:-for gpioint0, it should be

root@smarc-rzg2l:~# cat /proc/interrupts | grep SW
 82:          0          0 11030000.pinctrl 0 Edge      XXX

Not like

root@smarc-rzg2l:~# cat /proc/interrupts | grep SW
 82:          0          0 11030000.pinctrl 120 Edge      XXX

Cheers,
Biju
quoted
 chip:    GICv3
  flags:   0x15
             IRQCHIP_SET_TYPE_MASKED
             IRQCHIP_MASK_ON_SUSPEND
             IRQCHIP_SKIP_SET_WAKE

Now coming to current case,

Currently GPIO INT 0-122(123 interrupts) corresponding to
120-511(291 interrupts) with same invalid lines.

From a debugging point, If user has put same irq name for gpioints(cat
/proc/interrupts case), then how do we distinguish these interrupts??
(using hwirq??)
Yes.
quoted
For using Debugfs, Do we need to first execute cat /proc/interrupts to
get virq and from there we need to use virq to get statistics, right?
It depends what you want to do. /sys/kernel/debug/irq/irqs/ has the exact
same information. The only thing /proc/interrupts has that debugfs doesn't
is the per-CPU accounting of delivered interrupts.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help