Re: [QUERY] : pinmux-pins GPIO interrupt pin

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Tue, Oct 8, 2024 at 11:46 AM Lad, Prabhakar
<prabhakar.csengg@xxxxxxxxx> wrote:

> When using GPIO pins as interrupts with the `gpios` DT property, it
> follows the `gpio_request()`/`gpio_free()` path, and in this case, the
> `pinmux-pins` sysfs file indicates that the pin is claimed by the
> pinctrl/GPIO driver.
>
> However, when the same GPIO pin is used as an interrupt with the
> `interrupts` property, it doesn't follow the
> `gpio_request()`/`gpio_free()` path, and the `pinmux-pins` sysfs file
> shows it as `UNCLAIMED`.
>
> What would be the correct approach when using GPIO pins as interrupts
> with the `interrupts` property?

As mentioned on IRC:

In theory the GPIO and irqchip abstractions are completely orthogonal.

It should be entirely possible to use a GPIO as input GPIO, conveniently look
up the IRQ wiith gpiod_to_irq() enable interrupt on it and have that going for
a while, then disable IRQs, turn it into an output and bitbang it a bit, then
turn it back into an input and enable IRQs again.

drivers/media/cec/platform/cec-gpio/cec-gpio.c
is a driver that does this complex manouver...

> One possible solution could be to hog the GPIO pin as an input when
> using it as an interrupt with the `interrupts` property, ensuring it
> is claimed by the pinctrl/GPIO driver.

The driver should call these functions from <linux/gpio/driver.h>
to make sure the GPIO is "locked" as IRQ when used as IRQ
by an irqchip:

int gpiochip_lock_as_irq(struct gpio_chip *gc, unsigned int offset);
void gpiochip_unlock_as_irq(struct gpio_chip *gc, unsigned int offset);

This makes it impossible to request the GPIO as output (which
would be a disaster) but it can still be requested as input,
we can read the line even if it is used with IRQs.

Doesn't your GPIO driver call these functions?

Yours,
Linus Walleij