Re: [PATCH v3 3/4] sched: scheduler-driven cpu frequency selection

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Hi,

On Mon, Jun 29, 2015 at 09:49:43AM -0700, Michael Turquette wrote:

<snip>

> > > +static int cpufreq_sched_stop(struct cpufreq_policy *policy)
> > > +{
> > > +     struct gov_data *gd = policy->governor_data;
> > > +
> > > +     if (cpufreq_driver_might_sleep()) {
> > 
> > unnecessary curly braces.
> > 
> > > +             kthread_stop(gd->task);
> > 
> 
> Thanks for the review. I'll take into account everything above.
> 
> > should you switch back to some default OPP when this is removed ? Some
> > SoCs can't run at certain OPPs forever (thermal limitations, or whatever
> > else), might be good to switch to something considered safe.
> 
> The above only happens when we unload the module or switch governors,
> and every governor has this characteristic.
> 
> I do not think that open-coding a return to some default opp in every
> governor is a good solution. This sounds like something the cpufreq core
> should take care of.

indeed.

> Also, how do we know which opp is safe?

no idea, that needs to be described somehow.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]