On Wednesday, April 17, 2013 06:58:21 PM Rajagopal Venkat wrote:
Devfreq core runtime suspend/resume of a device is explicitly handled by devfreq driver using devfreq_suspend_device() and devfreq_resume_device() apis typically called from runtime suspend/resume callbacks. This patch aims to take away this from devfreq drivers and handle it from runtime-pm core. So that devfreq core runtime suspend/resume of a device is automatically done with runtime pm suspend/resume. The devfreq drivers shouldn't be concerned on when to suspend/resume the devfreq.
I agree, but perhaps there's a better way to achieve that than fumbling in the PM core?
Did you consider using a PM domain for that?
This patch is targeted to handle devfreq core load monitoring runtime suspend/resume only. Not the actual hardware itself. All the resources like clocks and regulators must still be handled by device driver using runtime-pm. The sequence of devfreq and device runtime suspend/resume is,
pm_runtime_suspend(dev) will first suspend device devfreq (if available) before device is suspended to ensure devfreq load monitoring is stopped and no device resources like clocks are accessed while device suspend is in progress.
pm_runtime_resume(dev) will resume device devfreq(if available) after device is resumed to ensure device resources like clocks are ready for use.
As devfreq runtime suspend/resume is done automatically from runtime core, this patch removes the existing devfreq_suspend_device() and devfreq_resume_device() apis.
Signed-off-by: Rajagopal Venkat rajagopal.venkat@linaro.org
I'm having a problem with this patch, because it's adding overhead into rpm_suspend() and rpm_resume() for all devices, even though many of them may not use devfreq. Worse yet, there are systems in which devfreq will never be used at all.
Thanks, Rafael