On Tuesday, February 25, 2014 11:38:14 AM Viresh Kumar wrote: > On 25 February 2014 11:23, Srivatsa S. Bhat > <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote: > > Hmm, that's a good point. However, lets first think about the simple scenario > > that the driver _is_ able to detect the current frequency from the hardware > > (a non-zero, sane value) say X KHz, and that frequency is different from what > > the cpufreq subsystem thinks it is (Y KHz). > > > > In the current code, when we observe this, we send out a notification and try > > to adjust to X KHz. Instead, what I'm suggesting is to invoke the driver to > > set the frequency to Y KHz, since that's what the cpufreq subsystems wants the > > frequency to be at. > > Actually we don't know at this point what cpufreq wants :) > Governor will decide what frequency to run CPU at and lets leave it to > that point. > As the transition that we might end up doing here would be simply overridden > very soon. And to be honest this decision must be taken by governor and not > core. We just want to make sure core is in sync with hardware. Well, why exactly does the core need to operate "current frequency" at all? Rafael -- 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
