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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,

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

> 
> >  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.
> 
> >
> > 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.







[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux