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.ven...@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 -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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/
