On 21 March 2013 20:32, Alan Stern stern@rowland.harvard.edu wrote:
On Thu, 21 Mar 2013, Rajagopal Venkat wrote:
Allow device devfreq to be suspend/resume automatically with runtime pm suspend/resume. The devfreq drivers should be least cared when to suspend/resume the devfreq.
pm_runtime_suspend(dev) will first suspend device devfreq(if available) before device is suspended from runtime pm core.
pm_runtime_resume(dev) will resume device devfreq(if available) after device is resumed from runtime pm core.
Aren't these backward? The device continues to need its clocks and frequency settings until _after_ it has been suspended. Similarly, it needs them to be available _before_ it resumes.
To clarify, devfreq suspend/resume means suspend/resume of load monitoring of a device. The clocks and other resources are still taken care by the devfreq driver runtime-pm callbacks. The devfreq must be suspended _before_ runtime-pm suspend callback in order to stop load monitoring while device is suspending. Similarly devfreq resume should happen _after_ runtime-pm resume callback.
Just realised both devfreq suspend/resume are done _before_ invoking runtime-pm callbacks. I will fix this up. Thanks.
Alan Stern