Re: [RFC PATCH] cpufreq: cpufreq-cpu0: do not allow transitions withregulators suspended

[Nishanth Menon]

On 11/14/2013 10:46 AM, viresh kumar wrote:
> On Thursday 14 November 2013 07:57 PM, Nishanth Menon wrote:
>> I am guessing this is a little too early for restarting policy here
>> considering syscore_ops->resume is pretty early..
> 
> Yeah, looks like that..
> 
>> http://pastebin.mozilla.org/3602746 is the equivalent patch for v3.12
>> http://pastebin.mozilla.org/3602747 is the result.
> 
> Can you try this instead of last diff I sent?
> 
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index dc67fa0..e70e906 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1324,6 +1324,15 @@ static void handle_update(struct work_struct *work)
>                 container_of(work, struct cpufreq_policy, update);
>         unsigned int cpu = policy->cpu;
>         pr_debug("handle_update for cpu %u called\n", cpu);
> +
> +       if (has_target() && !policy->governor_enabled) {
> +               if ((ret = __cpufreq_governor(policy, CPUFREQ_GOV_START)) ||
> +                       (ret = __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS))) {
> +                       pr_err("%s: Failed to start governor\n", __func__);
> +                       goto fail;
> +               }
> +       }
> +
>         cpufreq_update_policy(cpu);
>  }
> 
> 
I think it is still too early to do so :(

equivalent patch: http://pastebin.mozilla.org/3603467 (with minor
changes for build)

Basic tests: http://pastebin.mozilla.org/3603456 (governor is
functional, but governor kicks in early before i2c is resumed)

With call stack: http://pastebin.mozilla.org/3603455 to highlight call
sequences

Seems like we might want to pause governor as early in the suspend
sequence as possible to allow SoC and regulator stuff to suspend
themselves without cpufreq interfering.. just my 2 cents..

-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/