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 09:58:04
Also in: linux-gpio, linux-renesas-soc, lkml

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 [off-list ref] wrote:
quoted
Hi Marc,

.org>; Phil Edworthy
quoted
[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,
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help