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. > As for the case where the driver reports the frequency to be 0 KHz, we can > print a WARN() and try to force set the frequency to Y KHz. But if that turns > out to be too tricky to handle, we can just put a WARN() and error out, as you > proposed earlier. Ok.. -- 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
