linux-stable.git/drivers/cpufreq, branch v6.8.2

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

2024-03-26T22:17:32+00:00

[ Upstream commit f37a4d6b4a2c77414e8b9d25dd5ee31537ce9b00 ]

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 
Signed-off-by: Sasha Levin

cpufreq: qcom-hw: add CONFIG_COMMON_CLK dependency

2024-03-26T22:16:44+00:00

[ Upstream commit 3093fa33539b54db77171d2919352ad4f044a1c5 ]

It is still possible to compile-test a kernel without CONFIG_COMMON_CLK
for some ancient ARM boards or other architectures, but this causes a
link failure in the qcom-cpufreq-hw driver:

ERROR: modpost: "devm_clk_hw_register" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!
ERROR: modpost: "devm_of_clk_add_hw_provider" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!
ERROR: modpost: "of_clk_hw_onecell_get" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!

Add a Kconfig dependency here to make sure this always work. Apparently
this bug has been in the kernel for a while without me running into it
on randconfig builds as COMMON_CLK is almost always enabled.

I have cross-checked by building an allmodconfig kernel with COMMON_CLK
disabled, which showed no other driver having this problem.

Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: mediatek-hw: Don't error out if supply is not found

2024-03-26T22:16:34+00:00

[ Upstream commit eaffb10b51bf74415c9252fd8fb4dd77122501ee ]

devm_regulator_get_optional() returns -ENODEV if no supply can be found.
By introducing its usage, commit 788715b5f21c ("cpufreq: mediatek-hw:
Wait for CPU supplies before probing") caused the driver to fail probe
if no supply was present in any of the CPU DT nodes.

Use devm_regulator_get() instead since the CPUs do require supplies
even if not described in the DT. It will gracefully return a dummy
regulator if none is found in the DT node, allowing probe to succeed.

Fixes: 788715b5f21c ("cpufreq: mediatek-hw: Wait for CPU supplies before probing")
Reported-by: kernelci.org bot 
Closes: https://linux.kernelci.org/test/case/id/65b0b169710edea22852a3fa/
Signed-off-by: Nícolas F. R. A. Prado 
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: mediatek-hw: Wait for CPU supplies before probing

2024-03-26T22:16:32+00:00

[ Upstream commit 788715b5f21c6455264fe00a1779e61bec407fe2 ]

Before proceeding with the probe and enabling frequency scaling for the
CPUs, make sure that all supplies feeding the CPUs have probed.

This fixes an issue observed on MT8195-Tomato where if the
mediatek-cpufreq-hw driver enabled the hardware (by writing to
REG_FREQ_ENABLE) before the SPMI controller driver (spmi-mtk-pmif),
behind which lies the big CPU supply, probed the platform would hang
shortly after with "rcu: INFO: rcu_preempt detected stalls on
CPUs/tasks" being printed in the log.

Fixes: 4855e26bcf4d ("cpufreq: mediatek-hw: Add support for CPUFREQ HW")
Signed-off-by: Nícolas F. R. A. Prado 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Matthias Brugger 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value

2024-03-26T22:16:32+00:00

[ Upstream commit f661017e6d326ee187db24194cabb013d81bc2a6 ]

cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs")
Signed-off-by: Anastasia Belova 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: intel_pstate: fix pstate limits enforcement for adjust_perf call back

2024-02-24T14:01:59+00:00

There is a loophole in pstate limit clamping for the intel_cpufreq CPU
frequency scaling driver (intel_pstate in passive mode), schedutil CPU
frequency scaling governor, HWP (HardWare Pstate) control enabled, when
the adjust_perf call back path is used.

Fix it.

Fixes: a365ab6b9dfb cpufreq: intel_pstate: Implement the ->adjust_perf() callback
Signed-off-by: Doug Smythies 
Signed-off-by: Rafael J. Wysocki

cpufreq/amd-pstate: Fix setting scaling max/min freq values

2024-01-22T19:35:58+00:00

Scaling min/max freq values were being cached and lagging a setting
each time.  Fix the ordering of the clamp call to ensure they work.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217931
Fixes: febab20caeba ("cpufreq/amd-pstate: Fix scaling_min_freq and scaling_max_freq update")
Signed-off-by: Mario Limonciello 
Reviewed-by: Wyes Karny 
Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Refine computation of P-state for given frequency

2024-01-22T14:18:11+00:00

On systems using HWP, if a given frequency is equal to the maximum turbo
frequency or the maximum non-turbo frequency, the HWP performance level
corresponding to it is already known and can be used directly without
any computation.

Accordingly, adjust the code to use the known HWP performance levels in
the cases mentioned above.

This also helps to avoid limiting CPU capacity artificially in some
cases when the BIOS produces the HWP_CAP numbers using a different
E-core-to-P-core performance scaling factor than expected by the kernel.

Fixes: f5c8cf2a4992 ("cpufreq: intel_pstate: hybrid: Use known scaling factor for P-cores")
Cc: 6.1+  # 6.1+
Tested-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-sleep', 'pm-cpufreq' and 'pm-qos' into pm

2024-01-16T11:23:24+00:00

* pm-sleep:
  PM: sleep: Restore asynchronous device resume optimization

* pm-cpufreq:
  Documentation: admin-guide: PM: Fix two typos
  cpufreq: intel_pstate: Update hybrid scaling factor for Meteor Lake

* pm-qos:
  PM: QoS: Use kcalloc() instead of kzalloc()

cpufreq: intel_pstate: Update hybrid scaling factor for Meteor Lake

2024-01-10T14:02:25+00:00

On some Meteor Lake platforms, maximum one core turbo frequency is not
observed. During hybrid performance to frequency conversion, the maximum
frequency is 100 MHz less. This results in requesting maximum frequency
100 MHz less.

For example when the max one core turbo is 4.9 GHz:
MSR HWP_CAPABILITIES shows highest performance ratio for P-core is 0x3E.
With the current scaling factor of 78741 (1.27x for converting frequency
to performance) results in max frequency of 4.8 GHz. This results in
capping the max scaling frequency as 4.8 GHz, which is 100 MHz less than
the desired.

Add capability to define per CPU model specific scaling factor and define
scaling factor of 80000 (1.25x for converting frequency to performance for
P-cores) for Meteor Lake.

Signed-off-by: Srinivas Pandruvada 
[ rjw: Debug message adjustment, subject edit ]
Signed-off-by: Rafael J. Wysocki