Quoting Rafael J. Wysocki (2016-02-22 17:31:09) > On Tue, Feb 23, 2016 at 2:22 AM, Steve Muckle <steve.muc...@linaro.org> wrote: > > From: Michael Turquette <mturque...@baylibre.com> > > > > Some architectures and platforms perform CPU frequency transitions > > through a non-blocking method, while some might block or sleep. Even > > when frequency transitions do not block or sleep they may be very slow. > > This distinction is important when trying to change frequency from > > a non-interruptible context in a scheduler hot path. > > > > Describe this distinction with a cpufreq driver flag, > > CPUFREQ_DRIVER_FAST. The default is to not have this flag set, > > thus erring on the side of caution. > > > > cpufreq_driver_is_slow() is also introduced in this patch. Setting > > the above flag will allow this function to return false. > > > > [smuc...@linaro.org: change flag/API to include drivers that are too > > slow for scheduler hot paths, in addition to those that block/sleep] > > > > Cc: Rafael J. Wysocki <raf...@kernel.org> > > Cc: Viresh Kumar <viresh.ku...@linaro.org> > > Signed-off-by: Michael Turquette <mturque...@baylibre.com> > > Signed-off-by: Steve Muckle <smuc...@linaro.org> > > Something more sophisticated than this is needed, because one driver > may actually be able to do "fast" switching in some cases and may not > be able to do that in other cases.
Those drivers can set the flag dynamically when they probe based on their ACPI tables. > > For example, in the acpi-cpufreq case all depends on what's there in > the ACPI tables. It's all a moot point until the locking in cpufreq is changed. Until those changes are made it is a bad idea to call cpufreq_driver_target() from schedule() context, regardless of the underlying hardware, and all platforms should kick that work out to the kthread. Regards, Mike > > Thanks, > Rafael
