ACK: [PATCH 1/1][SRU][B][OEM-B] PM / runtime: Rework pm_runtime_force_suspend/resume()
Kleber Souza
kleber.souza at canonical.com
Tue Mar 31 13:02:33 UTC 2020
On 31.03.20 03:52, AceLan Kao wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
>
> BugLink: https://bugs.launchpad.net/bugs/1869642
>
> One of the limitations of pm_runtime_force_suspend/resume() is that
> if a parent driver wants to use these functions, all of its child
> drivers generally have to do that too because of the parent usage
> counter manipulations necessary to get the correct state of the parent
> during system-wide transitions to the working state (system resume).
> However, that limitation turns out to be artificial, so remove it.
>
> Namely, pm_runtime_force_suspend() only needs to update the children
> counter of its parent (if there's is a parent) when the device can
> stay in suspend after the subsequent system resume transition, as
> that counter is correct already otherwise. Now, if the parent's
> children counter is not updated, it is not necessary to increment
> the parent's usage counter in that case any more, as long as the
> children counters of devices are checked along with their usage
> counters in order to decide whether or not the devices may be left
> in suspend after the subsequent system resume transition.
>
> Accordingly, modify pm_runtime_force_suspend() to only call
> pm_runtime_set_suspended() for devices whose usage and children
> counters are at the "no references" level (the runtime PM status
> of the device needs to be updated to "suspended" anyway in case
> this function is called once again for the same device during the
> transition under way), drop the parent usage counter incrementation
> from it and update pm_runtime_force_resume() to compensate for these
> changes.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
> Reviewed-by: Ulf Hansson <ulf.hansson at linaro.org>
> (cherry picked from commit 4918e1f87c5fb7fc8f73a7d8fb118beeb94e05f7)
> Signed-off-by: AceLan Kao <acelan.kao at canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>
> ---
> drivers/base/power/runtime.c | 74 +++++++++++++++++-------------------
> 1 file changed, 34 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 6e89b51ea3d9..84832f1a75bf 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1613,17 +1613,28 @@ void pm_runtime_drop_link(struct device *dev)
> spin_unlock_irq(&dev->power.lock);
> }
>
> +static bool pm_runtime_need_not_resume(struct device *dev)
> +{
> + return atomic_read(&dev->power.usage_count) <= 1 &&
> + atomic_read(&dev->power.child_count) == 0;
> +}
> +
> /**
> * pm_runtime_force_suspend - Force a device into suspend state if needed.
> * @dev: Device to suspend.
> *
> * Disable runtime PM so we safely can check the device's runtime PM status and
> - * if it is active, invoke it's .runtime_suspend callback to bring it into
> - * suspend state. Keep runtime PM disabled to preserve the state unless we
> - * encounter errors.
> + * if it is active, invoke its ->runtime_suspend callback to suspend it and
> + * change its runtime PM status field to RPM_SUSPENDED. Also, if the device's
> + * usage and children counters don't indicate that the device was in use before
> + * the system-wide transition under way, decrement its parent's children counter
> + * (if there is a parent). Keep runtime PM disabled to preserve the state
> + * unless we encounter errors.
> *
> * Typically this function may be invoked from a system suspend callback to make
> - * sure the device is put into low power state.
> + * sure the device is put into low power state and it should only be used during
> + * system-wide PM transitions to sleep states. It assumes that the analogous
> + * pm_runtime_force_resume() will be used to resume the device.
> */
> int pm_runtime_force_suspend(struct device *dev)
> {
> @@ -1646,17 +1657,18 @@ int pm_runtime_force_suspend(struct device *dev)
> goto err;
>
> /*
> - * Increase the runtime PM usage count for the device's parent, in case
> - * when we find the device being used when system suspend was invoked.
> - * This informs pm_runtime_force_resume() to resume the parent
> - * immediately, which is needed to be able to resume its children,
> - * when not deferring the resume to be managed via runtime PM.
> + * If the device can stay in suspend after the system-wide transition
> + * to the working state that will follow, drop the children counter of
> + * its parent, but set its status to RPM_SUSPENDED anyway in case this
> + * function will be called again for it in the meantime.
> */
> - if (dev->parent && atomic_read(&dev->power.usage_count) > 1)
> - pm_runtime_get_noresume(dev->parent);
> + if (pm_runtime_need_not_resume(dev))
> + pm_runtime_set_suspended(dev);
> + else
> + __update_runtime_status(dev, RPM_SUSPENDED);
>
> - pm_runtime_set_suspended(dev);
> return 0;
> +
> err:
> pm_runtime_enable(dev);
> return ret;
> @@ -1669,13 +1681,9 @@ EXPORT_SYMBOL_GPL(pm_runtime_force_suspend);
> *
> * Prior invoking this function we expect the user to have brought the device
> * into low power state by a call to pm_runtime_force_suspend(). Here we reverse
> - * those actions and brings the device into full power, if it is expected to be
> - * used on system resume. To distinguish that, we check whether the runtime PM
> - * usage count is greater than 1 (the PM core increases the usage count in the
> - * system PM prepare phase), as that indicates a real user (such as a subsystem,
> - * driver, userspace, etc.) is using it. If that is the case, the device is
> - * expected to be used on system resume as well, so then we resume it. In the
> - * other case, we defer the resume to be managed via runtime PM.
> + * those actions and bring the device into full power, if it is expected to be
> + * used on system resume. In the other case, we defer the resume to be managed
> + * via runtime PM.
> *
> * Typically this function may be invoked from a system resume callback.
> */
> @@ -1684,32 +1692,18 @@ int pm_runtime_force_resume(struct device *dev)
> int (*callback)(struct device *);
> int ret = 0;
>
> - callback = RPM_GET_CALLBACK(dev, runtime_resume);
> -
> - if (!callback) {
> - ret = -ENOSYS;
> - goto out;
> - }
> -
> - if (!pm_runtime_status_suspended(dev))
> + if (!pm_runtime_status_suspended(dev) || pm_runtime_need_not_resume(dev))
> goto out;
>
> /*
> - * Decrease the parent's runtime PM usage count, if we increased it
> - * during system suspend in pm_runtime_force_suspend().
> - */
> - if (atomic_read(&dev->power.usage_count) > 1) {
> - if (dev->parent)
> - pm_runtime_put_noidle(dev->parent);
> - } else {
> - goto out;
> - }
> + * The value of the parent's children counter is correct already, so
> + * just update the status of the device.
> + */
> + __update_runtime_status(dev, RPM_ACTIVE);
>
> - ret = pm_runtime_set_active(dev);
> - if (ret)
> - goto out;
> + callback = RPM_GET_CALLBACK(dev, runtime_resume);
>
> - ret = callback(dev);
> + ret = callback ? callback(dev) : -ENOSYS;
> if (ret) {
> pm_runtime_set_suspended(dev);
> goto out;
>
More information about the kernel-team
mailing list