Messages in this thread | | | Date | Fri, 22 Mar 2013 14:35:07 +0530 | Subject | Re: [PATCH 2/2] PM / devfreq: tie suspend/resume to runtime-pm | From | Rajagopal Venkat <> |
| |
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 >
-- Regards, Rajagopal
| |