RE: [PATCH V3] PM / devfreq: tie suspend/resume to runtime-pm

["myungjoo.ham" <myungjoo.ham@samsung.com>]

From: Rafael J. Wysocki [mailto:rjw@sisk.pl] 
> 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?

As genpd_add_device seems to allow a device to register multiple domains, it seems fine. We need to ensure that there is only one device for the devfreq domain though.

pm_domain seems to be an overkill; however, the excessive overhead seems to be there only for register/unregister and that seems acceptable.

> 
> > 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

I thought about having the polling loop to check if the device is running or not before getting usage statistics. But we still need something to notify resume.


> 
> 
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
>

Cheers,
MyungJoo