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

Biju Das
2022-05-15T05:13:46Z

Hi Prabhakar,

Thanks for the example.

> Subject: Re: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain
> to handle GPIO interrupt
>
> > But "offset" is a number from the GPIO offset space (0-122), while
>
> The "offset" reported by kernel is 120-511:
>
> root@smarc-rzg2l:~# cat /sys/kernel/debug/gpio
> gpiochip0: GPIOs 120-511, parent: platform/11030000.pinctrl,
> 11030000.pinctrl:
> gpio-120 (P0_0 )
> gpio-121 (P0_1 )
> gpio-122 (P0_2 )
> gpio-123 (P0_3 )
> gpio-124 (P0_4 )
> .....
> gpio-507 (P48_3 )
> gpio-508 (P48_4 )
> gpio-509 (P48_5 )
> gpio-510 (P48_6 )
> gpio-511 (P48_7 )
>
> > irq_find_mapping() expects a number from the domain's IRQ space, which
> > is only 0-31?
> >
> Nope, let me demonstrate with an example, I have configured the gpio pins
> as GPIO keys in DTS:
>
> + keyboard {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + key-1 {
> + gpios = <&pinctrl RZG2L_GPIO(43, 0)
> GPIO_ACTIVE_HIGH>;
> + linux,code = <KEY_1>;
> + linux,input-type = <EV_KEY>;
> + wakeup-source;
> + label = "SW1";
> + };
> +
> + key-2 {
> + gpios = <&pinctrl RZG2L_GPIO(41, 0)
> GPIO_ACTIVE_HIGH>;
> + linux,code = <KEY_2>;
> + linux,input-type = <EV_KEY>;
> + wakeup-source;
> + label = "SW2";
> + };
> +
> + key-3 {
> + gpios = <&pinctrl RZG2L_GPIO(43, 1)
> GPIO_ACTIVE_HIGH>;
> + linux,code = <KEY_3>;
> + linux,input-type = <EV_KEY>;
> + wakeup-source;
> + label = "SW3";
> + };
> + };
>
> root@smarc-rzg2l:~# cat /proc/interrupts | grep SW root@smarc-rzg2l:~#
> root@smarc-rzg2l:~# insmod gpio_keys.ko [ 925.002720] input: keyboard as
> /devices/platform/keyboard/input/input3
> root@smarc-rzg2l:~# cat /proc/interrupts | grep SW
> 82: 0 0 11030000.pinctrl 344 Edge SW1
> 83: 0 0 11030000.pinctrl 328 Edge SW2
> 84: 0 0 11030000.pinctrl 345 Edge SW3
> root@smarc-rzg2l:~#
>
> In here 82/83/84 are virq and 344/328/345 are hwirq, which can be confirmed
> from sysfs file:

From your example, Looks like

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

May be another mapping required for pinindex to gpioint to get proper statistics??

From usage point, another point is, who will track gpioint statistics, pinctrl driver or framework??

Example Use case:- create gpioint0-30 which will fill tint0-tint30.

Then insmod gpioint corresponding to SW1 and trigger 1 interrupt and check cat /proc/interrupts for tint31 and SW1
Then rmmode gpioint corresponding to SW1 and insmod SW2 and trigger 5 interrupts and check cat /proc/interrupts for tint31 and SW2
Then rmmode gpioint corresponding to SW2 and insmod SW3 and trigger 7 interrupts and check cat /proc/interrupts for tint31 and SW3
Then rmmode gpioint corresponding to SW3 and insmod SW1 and check cat /proc/interrupts for tint31 and SW1
Then rmmode gpioint corresponding to SW1 and insmod SW2 and check cat /proc/interrupts for tint31 and SW2

Tint31 should report 13 interrupts
gpioint corresponding to SW1 should report 1 interrupt
gpioint corresponding to SW2 should report 5 interrupts
gpioint corresponding to SW3 should report 7 interrupts

Cheers,
Biju