| Message ID | 20210304192843.216829-1-ulf.hansson@linaro.org |
|---|---|
| State | Accepted |
| Commit | c1df456d0f06eb9275c1cd4c66548fc5738ea428 |
| Headers | show |
| Series | PM: domains: Don't runtime resume devices at genpd_prepare() | expand |
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!
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)
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(-) -- 2.25.1