[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZXlZ2i0wvI9iu3tv@google.com>
Date: Tue, 12 Dec 2023 23:14:34 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Tony Lindgren <tony@...mide.com>
Cc: Rob Herring <robh@...nel.org>, linux-input@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Dhruva Gole <d-gole@...com>
Subject: Re: [PATCH v5 2/2] Input: gpio-keys - Add system suspend support for
dedicated wakeirqs
On Wed, Nov 29, 2023 at 01:06:15PM +0200, Tony Lindgren wrote:
> Some SoCs have a separate dedicated wake-up interrupt controller that can
> be used to wake up the system from deeper idle states. We already support
> configuring a separate interrupt for a gpio-keys button to be used with a
> gpio line. However, we are lacking support system suspend for cases where
> a separate interrupt needs to be used in deeper sleep modes.
>
> Because of it's nature, gpio-keys does not know about the runtime PM state
> of the button gpios, and may have several gpio buttons configured for each
> gpio-keys device instance. Implementing runtime PM support for gpio-keys
> does not help, and we cannot use drivers/base/power/wakeirq.c support. We
> need to implement custom wakeirq support for gpio-keys.
>
> For handling a dedicated wakeirq for system suspend, we enable and disable
> it with gpio_keys_enable_wakeup() and gpio_keys_disable_wakeup() that we
> already use based on device_may_wakeup().
>
> Some systems may have a dedicated wakeirq that can also be used as the
> main interrupt, this is already working for gpio-keys. Let's add some
> wakeirq related comments while at it as the usage with a gpio line and
> separate interrupt line may not be obvious.
>
> Tested-by: Dhruva Gole <d-gole@...com>
> Signed-off-by: Tony Lindgren <tony@...mide.com>
Applied, thank you.
--
Dmitry
Powered by blists - more mailing lists