lkml.org 
[lkml]   [2022]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain to handle GPIO interrupt
Date
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

\
 
 \ /
  Last update: 2022-05-16 11:59    [W:0.098 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site