linux.git/drivers/cpufreq/freq_table.c, branch for-next

cpufreq: Fix up printing large CPU numbers and frequency values

2024-04-30T10:55:01+00:00

A negative CPU number or frequency value may be printed if they are
really large (which is unlikely, though).

Signed-off-by: Joshua Yeong 
Reviewed-by: Thorsten Blum 
Acked-by: Viresh Kumar 
[ rjw: Subject and changelog edits. ]
Signed-off-by: Rafael J. Wysocki

cpufreq: Use a smaller freq for the policy->max when verify

2024-03-27T15:19:39+00:00

When driver use the cpufreq_frequency_table_verify() as the
cpufreq_driver->verify's callback. It may cause the policy->max
bigger than the freq_qos's max freq.

Just as follow:

unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_available_frequencies
614400 768000 988000 1228800 1469000 1586000 1690000 1833000 2002000 2093000

unisoc:/sys/devices/system/cpu/cpufreq/policy0 # echo 1900000 > scaling_max_freq
unisoc:/sys/devices/system/cpu/cpufreq/policy0 # echo 1900000 > scaling_min_freq
unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_max_freq
2002000
unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_min_freq
2002000

When user set the qos_min and qos_max as the same value, and the value
is not in the freq-table, the above scenario will occur.

This is because in cpufreq_frequency_table_verify() func, when it can not
find the freq in table, it will change the policy->max to be a bigger freq,
as above, because there is no 1.9G in the freq-table, the policy->max would
be set to 2.002G. As a result, the cpufreq_policy->max is bigger than the
user's qos_max. This is unreasonable.

So use a smaller freq when can not find the freq in fre-table, to prevent
the policy->max exceed the qos's max freq.

Signed-off-by: Xuewen Yan 
Acked-by: Viresh Kumar 
Reviewed-by: Dhruva Gole 
Signed-off-by: Rafael J. Wysocki

cpufreq: Fix per-policy boost behavior on SoCs using cpufreq_boost_set_sw()

2024-03-13T19:57:00+00:00

In the existing code, per-policy flags don't have any impact i.e.
if cpufreq_driver boost is enabled and boost is disabled for one or
more of the policies, the cpufreq driver will behave as if boost is
enabled.

Fix this by incorporating per-policy boost flag in the policy->max
computation used in cpufreq_frequency_table_cpuinfo and setting the
default per-policy boost to mirror the cpufreq_driver boost flag.

Fixes: 218a06a79d9a ("cpufreq: Support per-policy performance boost")
Reported-by: Dietmar Eggemann 
Reviewed-by: Viresh Kumar 
Reviewed-by: Dhruva Gole 
Signed-off-by: Sibi Sankar 
Tested-by:Yipeng Zou  
Reviewed-by: Yipeng Zou  
Signed-off-by: Rafael J. Wysocki

Merge tag 'cpufreq-arm-updates-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm

2023-04-20T17:30:01+00:00

Pull cpufreq/ARM updates for 6.4 from Viresh Kumar:

"- Add opp and bandwidth support to tegra194 cpufreq driver (Sumit
   Gupta).

 - Use of_property_present() for testing DT property presence (Rob
   Herring).

 - Remove MODULE_LICENSE in non-modules (Nick Alcock).

 - Add SM7225 to cpufreq-dt-platdev blocklist (Luca Weiss).

 - Optimizations and fixes for qcom-cpufreq-hw driver (Krzysztof
   Kozlowski, Konrad Dybcio, and Bjorn Andersson).

 - DT binding updates for qcom-cpufreq-hw driver (Konrad Dybcio and
   Bartosz Golaszewski).

 - Updates and fixes for mediatek driver (Jia-Wei Chang and
   AngeloGioacchino Del Regno)."

cpufreq: drivers with target_index() must set freq_table

2023-04-07T11:21:58+00:00

Since the cpufreq core directly uses freq_table, for cpufreq drivers
that set their target_index() callback, make it mandatory for them to
set the same.

Since this is set per policy and normally from policy->init(), do this
from cpufreq_table_validate_and_sort() which gets called right after
->init().

Reported-by: Yajun Deng 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

kbuild, cpufreq: remove MODULE_LICENSE in non-modules

2023-03-13T04:27:43+00:00

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock 
Suggested-by: Luis Chamberlain 
Cc: Luis Chamberlain 
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa 
Cc: "Rafael J. Wysocki" 
Cc: Viresh Kumar 
Cc: linux-pm@vger.kernel.org
Signed-off-by: Viresh Kumar

cpufreq: Fix scaling_{available,boost}_frequencies_show() comments

2021-03-26T16:43:48+00:00

The function names in the comment blocks for the functions
scaling_available_frequencies_show() and
scaling_boost_frequencies_show() do not match the actual names.

Fixes: 6f19efc0a1ca08bc ("cpufreq: Add boost frequency support in core")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Rafael J. Wysocki

cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known

2021-02-18T17:34:56+00:00

Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover
boost frequencies") attempted to address a performance issue involving
acpi-cpufreq, the schedutil governor and scale-invariance on x86 by
extending the frequency tables created by acpi-cpufreq to cover the
entire range of "turbo" (or "boost") frequencies, but that caused
frequencies reported via /proc/cpuinfo and the scaling_cur_freq
attribute in sysfs to change which may confuse users and monitoring
tools.

For this reason, revert the part of commit 3c55e94c0ade adding the
extra entry to the frequency table and use the observation that
in principle cpuinfo.max_freq need not be equal to the maximum
frequency listed in the frequency table for the given policy.

Namely, modify cpufreq_frequency_table_cpuinfo() to allow cpufreq
drivers to set their own cpuinfo.max_freq above that frequency and
change  acpi-cpufreq to set cpuinfo.max_freq to the maximum boost
frequency found via CPPC.

This should be sufficient to let all of the cpufreq subsystem know
the real maximum frequency of the CPU without changing frequency
reporting.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=211305
Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Matt McDonald 
Tested-by: Matt McDonald 
Signed-off-by: Rafael J. Wysocki 
Tested-by: Giovanni Gherdovich 
Tested-by: Michael Larabel 
Cc: 5.11+  # 5.11+

cpufreq: freq_table: Demote obvious misuse of kerneldoc to standard comment blocks

2020-07-15T13:17:06+00:00

No attempt has been made to document any of the demoted functions here.

Fixes the following W=1 kernel build warning(s):

 drivers/cpufreq/freq_table.c:229: warning: Function parameter or member 'policy' not described in 'show_available_freqs'
 drivers/cpufreq/freq_table.c:229: warning: Function parameter or member 'buf' not described in 'show_available_freqs'
 drivers/cpufreq/freq_table.c:229: warning: Function parameter or member 'show_boost' not described in 'show_available_freqs'
 drivers/cpufreq/freq_table.c:269: warning: Function parameter or member 'policy' not described in 'scaling_available_frequencies_show'
 drivers/cpufreq/freq_table.c:269: warning: Function parameter or member 'buf' not described in 'scaling_available_frequencies_show'
 drivers/cpufreq/freq_table.c:281: warning: Function parameter or member 'policy' not described in 'scaling_boost_frequencies_show'
 drivers/cpufreq/freq_table.c:281: warning: Function parameter or member 'buf' not described in 'scaling_boost_frequencies_show'

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

cpufreq: Avoid creating excessively large stack frames

2020-01-27T09:33:33+00:00

In the process of modifying a cpufreq policy, the cpufreq core makes
a copy of it including all of the internals which is stored on the
CPU stack.  Because struct cpufreq_policy is relatively large, this
may cause the size of the stack frame to exceed the 2 KB limit and
so the GCC complains when -Wframe-larger-than= is used.

In fact, it is not necessary to copy the entire policy structure
in order to modify it, however.

First, because cpufreq_set_policy() obtains the min and max policy
limits from frequency QoS now, it is not necessary to pass the limits
to it from the callers.  The only things that need to be passed to it
from there are the new governor pointer or (if there is a built-in
governor in the driver) the "policy" value representing the governor
choice.  They both can be passed as individual arguments, though, so
make cpufreq_set_policy() take them this way and rework its callers
accordingly.  This avoids making copies of cpufreq policies in the
callers of cpufreq_set_policy().

Second, cpufreq_set_policy() still needs to pass the new policy
data to the ->verify() callback of the cpufreq driver whose task
is to sanitize the min and max policy limits.  It still does not
need to make a full copy of struct cpufreq_policy for this purpose,
but it needs to pass a few items from it to the driver in case they
are needed (different drivers have different needs in that respect
and all of them have to be covered).  For this reason, introduce
struct cpufreq_policy_data to hold copies of the members of
struct cpufreq_policy used by the existing ->verify() driver
callbacks and pass a pointer to a temporary structure of that
type to ->verify() (instead of passing a pointer to full struct
cpufreq_policy to it).

While at it, notice that intel_pstate and longrun don't really need
to verify the "policy" value in struct cpufreq_policy, so drop those
check from them to avoid copying "policy" into struct
cpufreq_policy_data (which allows it to be slightly smaller).

Also while at it fix up white space in a couple of places and make
cpufreq_set_policy() static (as it can be so).

Fixes: 3000ce3c52f8 ("cpufreq: Use per-policy frequency QoS")
Link: https://lore.kernel.org/linux-pm/CAMuHMdX6-jb1W8uC2_237m8ctCpsnGp=JCxqt8pCWVqNXHmkVg@mail.gmail.com
Reported-by: kbuild test robot 
Reported-by: Geert Uytterhoeven 
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar