linux-toradex.git/drivers/cpufreq/cpufreq_userspace.c, branch v6.19

cpufreq: userspace: set CPUFREQ_GOV_STRICT_TARGET flag

2025-06-18T19:33:01+00:00

When the userspace governor is used, the user intends to set a fixed CPU
frequency for a policy, for whatever reason. The CPUFREQ_GOV_STRICT_TARGET
flag is the required behaviour. Without this flag, the intel_pstate driver,
with HWP enabled, will set HWP_MIN_PERF to the target frequency and
HWP_MAX_PERF to the policy maximum, when configuring the HWP_REQUEST MSR.

This lets the hardware choose any frequency between the target frequency
and the policy maximum, which is not the intended behaviour. To fix this,
`cat scaling_setspeed > scaling_max_freq` had to be done. With this patch,
that is no longer necessary. Setting scaling_setspeed is sufficient, as
expected.

Signed-off-by: Shashank Balaji 
Link: https://patch.msgid.link/20250527-userspace-governor-doc-v2-1-0e22c69920f2@sony.com
Signed-off-by: Rafael J. Wysocki

cpufreq: userspace: Move is_managed indicator into per-policy structure

2023-10-06T20:01:26+00:00

The userspace governor uses the 'cpu' field of cpufreq_policy structure
to track if it is allowed to set the speed of the policy.

However, there is a window where the 'cpu' field is equal to the value
of nr_cpus_id when all affected CPUs of policy are offline, which is an
illegal value to get the per-CPU variable.

To avoid this issue, modify the governor to use a per-policy indicator
to track if the policy is managed.

Signed-off-by: Liao Chang 
Acked-by: Viresh Kumar 
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki

cpufreq: userspace: Use fine-grained mutex in userspace governor

2023-10-06T20:01:26+00:00

The userspace governor currently uses a big global mutex to avoid the
race condition on the governor_data field of cpufreq_policy structure.

This leads to a low concurrency if multiple userspace applications are
trying to set the speed of different policies at the same time.

Introduce a per-policy mutex to allow the updating of different policies
to be performed concurrently, improving overall concurrency.

Signed-off-by: Liao Chang 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Register governors at core_initcall

2020-07-02T11:03:30+00:00

Currently, most CPUFreq governors are registered at the core_initcall
time when the given governor is the default one, and the module_init
time otherwise.

In preparation for letting users specify the default governor on the
kernel command line, change all of them to be registered at the
core_initcall unconditionally, as it is already the case for the
schedutil and performance governors. This will allow us to assume
that builtin governors have been registered before the built-in
CPUFreq drivers probe.

And since all governors have similar init/exit patterns now, introduce
two new macros, cpufreq_governor_{init,exit}(), to factorize the code.

Acked-by: Viresh Kumar 
Signed-off-by: Quentin Perret 
Signed-off-by: Viresh Kumar 
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki

cpufreq: Initialize the governors in core_initcall

2019-11-07T06:00:26+00:00

Initialize the cpufreq governors earlier to allow for earlier
performance control during the boot process.

Signed-off-by: Amit Kucheria 
Acked-by: Viresh Kumar 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/b98eae9b44eb2f034d7f5d12a161f5f831be1eb7.1571656015.git.amit.kucheria@linaro.org

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55+00:00

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Enrico Weigelt 
Reviewed-by: Kate Stewart 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman

cpufreq: governor: Get rid of governor events

2016-06-02T21:24:15+00:00

The design of the cpufreq governor API is not very straightforward,
as struct cpufreq_governor provides only one callback to be invoked
from different code paths for different purposes.  The purpose it is
invoked for is determined by its second "event" argument, causing it
to act as a "callback multiplexer" of sorts.

Unfortunately, that leads to extra complexity in governors, some of
which implement the ->governor() callback as a switch statement
that simply checks the event argument and invokes a separate function
to handle that specific event.

That extra complexity can be eliminated by replacing the all-purpose
->governor() callback with a family of callbacks to carry out specific
governor operations: initialization and exit, start and stop and policy
limits updates.  That also turns out to reduce the code size too, so
do it.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar

cpufreq: Fix GOV_LIMITS handling for the userspace governor

2016-05-04T23:30:38+00:00

Currently, the userspace governor only updates frequency on GOV_LIMITS
if policy->cur falls outside policy->{min/max}. However, it is also
necessary to update current frequency on GOV_LIMITS to match the user
requested value if it can be achieved within the new policy->{max/min}.

This was previously the behaviour in the governor until commit d1922f0
("cpufreq: Simplify userspace governor") which incorrectly assumed that
policy->cur == user requested frequency via scaling_setspeed. This won't
be true if the user requested frequency falls outside policy->{min/max}.
Ex: a temporary thermal cap throttled the user requested frequency.

Fix this by storing the user requested frequency in a seperate variable.
The governor will then try to achieve this request on every GOV_LIMITS
change.

Fixes: d1922f02562f (cpufreq: Simplify userspace governor)
Signed-off-by: Sai Gurrappadi 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Clean up default and fallback governor setup

2016-02-05T01:37:42+00:00

The preprocessor magic used for setting the default cpufreq governor
(and for using the performance governor as a fallback one for that
matter) is really nasty, so replace it with __weak functions and
overrides.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Saravana Kannan 
Acked-by: Viresh Kumar

cpufreq / governor: Remove fossil comment

2013-10-17T21:00:20+00:00

cpufreq_set_policy() has been changed to origin __cpufreq_set_policy()
and policy->lock has been converted to rewrite lock by commit 5a01f2.
So remove the comment.

Acked-by: Viresh Kumar 
Signed-off-by: Lan Tianyu 
Signed-off-by: Rafael J. Wysocki