diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2012-12-22 23:59:01 +0100 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-01-06 00:35:55 +0100 |
commit | 9f6d8f6ab26b42620a914d67f29822f9bba90233 (patch) | |
tree | ac243fb6970bf2b870e34e061281f7ad5446ad38 /drivers/mmc | |
parent | d1c3ed669a2d452cacfb48c2d171a1f364dae2ed (diff) | |
download | op-kernel-dev-9f6d8f6ab26b42620a914d67f29822f9bba90233.zip op-kernel-dev-9f6d8f6ab26b42620a914d67f29822f9bba90233.tar.gz |
PM: Move disabling/enabling runtime PM to late suspend/early resume
Currently, the PM core disables runtime PM for all devices right
after executing subsystem/driver .suspend() callbacks for them
and re-enables it right before executing subsystem/driver .resume()
callbacks for them. This may lead to problems when there are
two devices such that the .suspend() callback executed for one of
them depends on runtime PM working for the other. In that case,
if runtime PM has already been disabled for the second device,
the first one's .suspend() won't work correctly (and analogously
for resume).
To make those issues go away, make the PM core disable runtime PM
for devices right before executing subsystem/driver .suspend_late()
callbacks for them and enable runtime PM for them right after
executing subsystem/driver .resume_early() callbacks for them. This
way the potential conflitcs between .suspend_late()/.resume_early()
and their runtime PM counterparts are still prevented from happening,
but the subtle ordering issues related to disabling/enabling runtime
PM for devices during system suspend/resume are much easier to avoid.
Reported-and-tested-by: Jan-Matthias Braun <jan_braun@gmx.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Cc: 3.4+ <stable@vger.kernel.org>
Diffstat (limited to 'drivers/mmc')
0 files changed, 0 insertions, 0 deletions