On 02/25/2014 10:11 AM, Viresh Kumar wrote:
On 18 February 2014 07:49, Viresh Kumar viresh.kumar@linaro.org wrote:
On 18 February 2014 03:30, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Monday, February 17, 2014 02:25:34 PM Srivatsa S. Bhat wrote:
Why go to no_policy when we can actually set things right?
Anyway, I am not arguing against this strongly. I just wanted to share my thoughts, since this is the approach that made more sense to me.
And I agree with that. In particular, since we're going to set the new policy *anyway* at this point, we can adjust the current frequency just fine in the process, can't we?
Though I still feel that it wouldn't be the right thing to do as get() just can't return zero. Actually I was planning to place a WARN() over its return value of zero.
A WARN() would definitely be good.
Anyway, as two of the three are in favor of this we can get that in.. But how would that work?
- What frequency should we call cpufreq_driver_target ?
- Remember that it wouldn't do anything if policy->cur is same as new freq.
- Also remember that drivers need special attention if new freq is > old
freq or vice versa. As they will change voltage before or after change here. And because we actually don't know what frequency we are at currently, how will we decide that?
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.
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.
Regards, Srivatsa S. Bhat