ACK: [PATCH 1/1][SRU][B][OEM-B] PM / runtime: Rework pm_runtime_force_suspend/resume()
Andrea Righi
andrea.righi at canonical.com
Tue Mar 31 14:01:52 UTC 2020
On Tue, Mar 31, 2020 at 09:52:00AM +0800, 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>
Looks good to me.
Acked-by: Andrea Righi <andrea.righi at canonical.com>
More information about the kernel-team
mailing list