lkml.org 
[lkml]   [2021]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] PM: domains: Don't runtime resume devices at genpd_prepare()
On Thu, Mar 4, 2021 at 8:30 PM Ulf Hansson <ulf.hansson@linaro.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@linaro.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!

\
 
 \ /
  Last update: 2021-03-18 19:43    [W:0.068 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site