The CPUfreq core does not differentiate between .target & .target_index callbacks that may sleep or block and callbacks that are fast and return immediately. To date this has not mattered much since the typical CPUfreq governor calls the .target callback from process context via a workqueue.
When calling the .target callback from a different context, such as a scheduler load balance operation (see Morten's "energy aware scheduler" RFC[0]), this detail matters. This patch introduces a new CPUfreq driver flag for fast .target callbacks that are guaranteed to neither sleep nor block. Setting this flag allows for .target to be called from schedule() and other call sites that have interrupts disabled or other constraints. Drivers may set CPUFREQ_NO_SLEEP at driver registration-time. The default is to not have this flag set, resulting in the need to defer calls to .target and .target_index. [0] http://lkml.kernel.org/r/<1381511957-29776-7-git-send-email-morten.rasmus...@arm.com> Signed-off-by: Mike Turquette <mturque...@linaro.org> --- include/linux/cpufreq.h | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 138336b..9034573 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -308,6 +308,19 @@ struct cpufreq_driver { */ #define CPUFREQ_NEED_INITIAL_FREQ_CHECK (1 << 5) +/* + * Set by drivers whose .target or .target_index callback will never sleep or + * block. Setting this flag allows for more optimal code by calling .target + * from a context that otherwise would require deferring the work. + * + * An example use of this flag is when scaling cpu frequency from within a call + * to schedule() with interrupts disabled and runqueue locks held. + * + * This flag is not set by default, causing calls to .target to be done in + * process context. + */ +#define CPUFREQ_NO_SLEEP (1 << 6) + int cpufreq_register_driver(struct cpufreq_driver *driver_data); int cpufreq_unregister_driver(struct cpufreq_driver *driver_data); -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
