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 cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
