On 21 March 2013 20:32, Alan Stern <st...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/