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
