On 11/20/2013 08:44 PM, Viresh Kumar wrote: > On 21 November 2013 02:36, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >> From: Stephen Warren <swarren@xxxxxxxxxx> >> >> d4019f0a92ab "cpufreq: move freq change notifications to cpufreq core" >> added code to the cpufreq core to print an error if a cpufreq driver's >> .target() function returned an error. This exposed the fact that Tegra's >> cpufreq driver returns an error when it is ignoring requests due to the >> system being suspended. >> >> Modify Tegra's .target() function not to return an error in this case; >> this prevents the error prints. The argument is that since the suspend >> hook can't and doesn't inform the cpufreq core when its requests will >> be ignored, there's no way for the cpufreq core to squelch them, so it's >> not an error for the requests to keep coming. This change make the Tegra >> driver consistent with how the Exynos handles the same situation. Note >> that s5pv210-cpufreq.c probably suffers from this same issue though. >> >> Signed-off-by: Stephen Warren <swarren@xxxxxxxxxx> > > Thanks.. > >> --- >> This is a fix for 3.13. >> >> Commit d4019f0a92ab also failed to update the Tegra pm_notifier hook to >> emit cpufreq notifications. That hook calls the target() implementation >> directly, which used to emit the notifications. However, now that the >> notifications are made outside of target(), they no longer occur when >> target() is called directly. I'm not sure if this is an issue or not? > > Hmm.. Yes and no.. Frequency after this point will not be in sync with > cpufreq core, but at the same time after resume cpufreq core will check > this out and get the correct frequency.. OK, sounds like I should ignore this issue then? -- 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
