On Sun, Apr 19, 2020 at 8:10 PM Dmitry Torokhov
[off-list ref] wrote:

On Tue, Mar 10, 2020 at 07:15:35AM +0000, BOUGH CHEN wrote:

quoted

quoted

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Sent: 2020年3月10日 12:27
To: BOUGH CHEN <haibo.chen@nxp.com>
Cc: linux-input@vger.kernel.org; dl-linux-imx <redacted>
Subject: Re: [PATCH 2/2] input: egalax_ts: free irq resource before request
the line as GPIO

On Tue, Feb 11, 2020 at 04:41:12PM +0800, haibo.chen@nxp.com wrote:

quoted

From: Haibo Chen <haibo.chen@nxp.com>

+ egalax_free_irq(ts);

It sounds to me you want simply disable interrupts in suspend. Does not
calling disable_irq() here suffice?

quoted

Here why I want to disable interrupts here is because in the newest
gpio system, if the gpio is request as an irq, it can't be request as
a gpio anymore.  In the function egalax_wake_up_device(), we need to
request the irq pin as a gpio for a while, generate a signal to wake
up the device. So before request the pad as gpio, need first free irq
resource.

This seems like a fairly common pattern and I wonder if our GPIO
overlords can help us here.

Linus, Mika, Andy, would it be possible to have an API that would allow
driver to temporarily "take over" GPIO that is used for interrupts and
drive it as output without resorting to freeing and re-acquiring irq?
I.e. something like gpiod_irq_drive_output_start() and
gpiod_irq_drive_output_end()?

Hans Verkuil had exactly this problem in the CEC GPIO driver,
drivers/media/platform/cec-gpio/cec-gpio.c

If you call disable_irq() on an irqchip implemented in a GPIO
driver using the generic GPIOLIB_IRQCHIP helper library (which
I really recommend) then the line can be switched to output,
used like such, then switched to input and enable_irq() be
called again.

See these commits:
commit 4e9439ddacea06f35acce4d374bf6bd0acf99bc8
"gpiolib: add flag to indicate if the irq is disabled"
commit 461c1a7d4733d1dfd5c47b040cf32a5e7eefbc6c
"gpiolib: override irq_enable/disable"

If your corresponding GPIO driver does not use GPIOLIB_IRQCHIP
then you have a bigger problem and we need to look into that.

Yours,
Linus Walleij