Re: [linux-pm] calling runtime PM from system PM methods

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 17 Jun 2011, Rafael J. Wysocki wrote:

> Having considered that a bit more I see that, in fact, commit
> e8665002477f0278f84f898145b1f141ba26ee26 (PM: Allow pm_runtime_suspend() to
> succeed during system suspend) has introduced at least one regression.
> Namely, the PCI bus type runs pm_runtime_resume() in its .prepare()
> callback to guarantee that devices will be in a well known state before
> the PCI .suspend() and .suspend_noirq() callbacks are executed.
> Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26 this
> isn't valid any more, because devices can be runtime-suspend after the
> pm_runtime_resume() in .prepare() has run.
> 
> USB seems to do something similar in choose_wakeup().
> 
> So, either the both of these subsystems should be modified to use
> pm_runtime_get_sync() and then pm_runtime_put_<something>() some time
> during resume, or we should revert commit e8665002477f0278f84f898145b1f141ba26ee26.

pm_runtime_put_noidle would be appropriate.

> Quite frankly, which shouldn't be a surprise to anyone at this point, I'd
> prefer to revert that commit for 3.0.

Maybe we can compromise.  Instead of reverting that commit outright,
put the get_noresume just before the suspend callback and put the
put_sync just after the resume callback.

The point is that some embedded systems may rely heavily on runtime PM
to keep power usage low, so we shouldn't prevent it from doing its job
during the entire prepare -> suspend window.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux