[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0h7PeqXXtj0J=JaBJkuMTvKXXOCN3xL5Omu6vej_vWCwg@mail.gmail.com>
Date: Thu, 18 Mar 2021 19:40:59 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: "Rafael J . Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>,
Lina Iyer <ilina@...eaurora.org>,
Kevin Hilman <khilman@...nel.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Heiko Stuebner <heiko@...ech.de>,
Matthias Brugger <matthias.bgg@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PM: domains: Don't runtime resume devices at genpd_prepare()
On Thu, Mar 4, 2021 at 8:30 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> Runtime resuming a device upfront in the genpd_prepare() callback, to check
> if there is a wakeup pending for it, seems like an unnecessary thing to do.
> The PM core already manages these kind of things in a common way in
> __device_suspend(), via calling pm_runtime_barrier() and
> pm_wakeup_pending().
>
> Therefore, let's simply drop this behaviour from genpd_prepare().
>
> Note that, this change is applicable only for devices that are attached to
> a genpd that has the GENPD_FLAG_ACTIVE_WAKEUP set (Renesas, Mediatek, and
> Rockchip platforms). Moreover, a driver that needs to restore power for its
> device to re-configure it for a system wakeup, may still call
> pm_runtime_get_sync(), for example, to do this.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
> ---
> drivers/base/power/domain.c | 36 ------------------------------------
> 1 file changed, 36 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 78c310d3179d..b6a782c31613 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1087,34 +1087,6 @@ static void genpd_sync_power_on(struct generic_pm_domain *genpd, bool use_lock,
> genpd->status = GENPD_STATE_ON;
> }
>
> -/**
> - * resume_needed - Check whether to resume a device before system suspend.
> - * @dev: Device to check.
> - * @genpd: PM domain the device belongs to.
> - *
> - * There are two cases in which a device that can wake up the system from sleep
> - * states should be resumed by genpd_prepare(): (1) if the device is enabled
> - * to wake up the system and it has to remain active for this purpose while the
> - * system is in the sleep state and (2) if the device is not enabled to wake up
> - * the system from sleep states and it generally doesn't generate wakeup signals
> - * by itself (those signals are generated on its behalf by other parts of the
> - * system). In the latter case it may be necessary to reconfigure the device's
> - * wakeup settings during system suspend, because it may have been set up to
> - * signal remote wakeup from the system's working state as needed by runtime PM.
> - * Return 'true' in either of the above cases.
> - */
> -static bool resume_needed(struct device *dev,
> - const struct generic_pm_domain *genpd)
> -{
> - bool active_wakeup;
> -
> - if (!device_can_wakeup(dev))
> - return false;
> -
> - active_wakeup = genpd_is_active_wakeup(genpd);
> - return device_may_wakeup(dev) ? active_wakeup : !active_wakeup;
> -}
> -
> /**
> * genpd_prepare - Start power transition of a device in a PM domain.
> * @dev: Device to start the transition of.
> @@ -1135,14 +1107,6 @@ static int genpd_prepare(struct device *dev)
> if (IS_ERR(genpd))
> return -EINVAL;
>
> - /*
> - * If a wakeup request is pending for the device, it should be woken up
> - * at this point and a system wakeup event should be reported if it's
> - * set up to wake up the system from sleep states.
> - */
> - if (resume_needed(dev, genpd))
> - pm_runtime_resume(dev);
> -
> genpd_lock(genpd);
>
> if (genpd->prepared_count++ == 0)
> --
Applied as 5.13 material, thanks!
Powered by blists - more mailing lists