On Wed, 3 Nov 2010, Rafael J. Wysocki wrote: > On Tuesday, November 02, 2010, Raj Kumar wrote: > > > > Hi, > > > > There is a one issue coming regarding the run time power management during system suspend, Suppose > > system suspend is going on and before the suspend callback of driver is executed, driver issues a runtime resume to run time power management core before it gets > > the system suspend call back but System suspend is going on then how the run time power management prevents this condition? > > > > As I saw the code during dpm_prepare, power usage count is incremented by 1 by calling pm_runtime_get_noresume(dev) and then it calls > > pm_runtime_barrier, > > > > Since During System suspend, driver calls pm_runtime_get which will invoke > > > > atomic_inc(&dev->power.usage_count); > > > > which increments the power usage count and calls pm_request_resume which does not have any check on power usage count, > > pm_request_resume() called during system suspend will not have any effect, unless it is called before > the pm_runtime_barrier() in dpm_prepare(), in which case the device is going to be resumed and > system suspend will be aborted, because the PM workqueue if frozen before the suspend of > devices. Should pm_request_resume be changed? Maybe it should abort a system sleep transition. Or maybe it should abort the sleep if the device in question has already been suspended. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
