On Thu, Jul 20, 2017 at 11:52:41AM +0200, Rafael J. Wysocki wrote: > On Thu, Jul 20, 2017 at 9:18 AM, Viresh Kumar <viresh.ku...@linaro.org> wrote: > > On 20-07-17, 01:17, Rafael J. Wysocki wrote: > >> On Thu, Jul 20, 2017 at 12:54 AM, Florian Fainelli <f.faine...@gmail.com> > >> wrote: > >> > Hi, > >> > > >> > We have a particular ARM CPU design that is drawing quite a lot of > >> > current upon exit from WFI, and it does so in a way even before the > >> > first instruction out of WFI is executed. That means we cannot influence > >> > directly the exit from WFI other than by changing the state in which it > >> > would be previously entered because of this "dead" time during which the > >> > internal logic needs to ramp up back where it left. > >> > > >> > A naive approach to solving this problem because we have CPU frequency > >> > scaling available would be to do the following: > >> > > >> > - just before entering WFI, switch to a low frequency OPP > >> > - enter WFI > >> > - upon exit from WFI, ramp up the frequency back to e.g: highest OPP > >> > > >> > Some of the parts that I am not exactly clear on would be: > >> > > >> > - would that qualify as a cpuidle governor of some kind that ties in > >> > which cpufreq? > >> > - would using cpufreq_driver_fast_switch() be an appropriate API to use > >> > from outside
Can your ARM part change OPP without scheduling? Because (for obvious reasons) the idle thread is not supposed to block.
