On 15 May 2014 23:43, Doug Anderson dianders@chromium.org wrote:
This will have the side effect of sending twice as many notifications. ...however it does allow for people registering for CPUFREQ notifications to be more generic...
That's not a side effect of this approach but the way platforms are handling it, and there is no way out we can skip that. In case we do, we will give space for the race to happen and udelay will work badly..
Thinking about it, I think you're right that this is the way to go.
Correct :)
It probably makes sense to wait until Thomas Abraham's patch lands, since he's redoing exynos cpufreq to use cpufreq-cpu0. ...and maybe Thomas would be willing to write this patch?
But cpufreq-cpu0 isn't handling this intermediate freq concept, how will you work around that? Anyway we can get this working for tegra if stephen agrees.
What do you think about calling this get_safe_freq(). It took me a little while before I realized that this function didn't perform the transition to the safe frequency--it just returned it.
...the comment adds extra confusion since it makes it sound like the switch happens right here.
Agree.
/* Send POST notification for the target frequency */
freqs.new = freq_table[index].frequency;
Don't you need to set freqs.old to the safe_freq?
Agree..