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

cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}()

2024-11-01T00:58:32+00:00

[ Upstream commit 50b813b147e9eb6546a1fc49d4e703e6d23691f2 ]

Move and rename cppc_cpufreq_perf_to_khz() and cppc_cpufreq_khz_to_perf() to
use them outside cppc_cpufreq in topology_init_cpu_capacity_cppc().

Modify the interface to use struct cppc_perf_caps *caps instead of
struct cppc_cpudata *cpu_data as we only use the fields of cppc_perf_caps.

cppc_cpufreq was converting the lowest and nominal freq from MHz to kHz
before using them. We move this conversion inside cppc_perf_to_khz and
cppc_khz_to_perf to make them generic and usable outside cppc_cpufreq.

No functional change

Signed-off-by: Vincent Guittot 
Signed-off-by: Ingo Molnar 
Tested-by: Pierre Gondois 
Acked-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
Link: https://lore.kernel.org/r/20231211104855.558096-6-vincent.guittot@linaro.org
Stable-dep-of: d93df29bdab1 ("cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception")
Signed-off-by: Sasha Levin

cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems

2024-11-01T00:58:18+00:00

[ Upstream commit c10e50a469b5ec91eabf653526a22bdce03a9bca ]

While switching the driver mode between active and passive, Collaborative
Processor Performance Control (CPPC) is disabled in
amd_pstate_unregister_driver(). But, it is not enabled back while registering
the new driver (passive or active). This leads to the new driver mode not
working correctly, so enable it back in amd_pstate_register_driver().

Fixes: 3ca7bc818d8c ("cpufreq: amd-pstate: Add guided mode control support via sysfs")
Signed-off-by: Dhananjay Ugwekar 
Reviewed-by: Mario Limonciello 
Link: https://lore.kernel.org/r/20241004122303.94283-1-Dhananjay.Ugwekar@amd.com
Signed-off-by: Mario Limonciello 
Signed-off-by: Sasha Levin

cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock

2024-10-10T09:58:01+00:00

commit 8b4865cd904650cbed7f2407e653934c621b8127 upstream.

notify_hwp_interrupt() is called via sysvec_thermal() ->
smp_thermal_vector() -> intel_thermal_interrupt() in hard irq context.
For this reason it must not use a simple spin_lock that sleeps with
PREEMPT_RT enabled. So convert it to a raw spinlock.

Reported-by: xiao sheng wen 
Link: https://bugs.debian.org/1076483
Signed-off-by: Uwe Kleine-König 
Acked-by: Srinivas Pandruvada 
Acked-by: Sebastian Andrzej Siewior 
Tested-by: xiao sheng wen 
Link: https://patch.msgid.link/20240919081121.10784-2-ukleinek@debian.org
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
[ukleinek: Backport to v6.6.y]
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Sasha Levin

cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately

2024-10-04T14:28:54+00:00

[ Upstream commit abc00ffda43bd4ba85896713464c7510c39f8165 ]

Commit b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx
and omap36xx") introduced special handling for OMAP3 class devices
where syscon node may not be present. However, this also creates a bug
where the syscon node is present, however the offset used to read
is beyond the syscon defined range.

Fix this by providing a quirk option that is populated when such
special handling is required. This allows proper failure for all other
platforms when the syscon node and efuse offsets are mismatched.

Fixes: b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx")
Signed-off-by: Nishanth Menon 
Tested-by: Dhruva Gole 
Reviewed-by: Kevin Hilman 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: amd-pstate: fix the highest frequency issue which limits performance

2024-09-12T09:11:40+00:00

commit bf202e654bfa57fb8cf9d93d4c6855890b70b9c4 upstream.

To address the performance drop issue, an optimization has been
implemented. The incorrect highest performance value previously set by the
low-level power firmware for AMD CPUs with Family ID 0x19 and Model ID
ranging from 0x70 to 0x7F series has been identified as the cause.

To resolve this, a check has been implemented to accurately determine the
CPU family and model ID. The correct highest performance value is now set
and the performance drop caused by the incorrect highest performance value
are eliminated.

Before the fix, the highest frequency was set to 4200MHz, now it is set
to 4971MHz which is correct.

CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
  0    0      0    0 0:0:0:0          yes 4971.0000 400.0000  400.0000
  1    0      0    0 0:0:0:0          yes 4971.0000 400.0000  400.0000
  2    0      0    1 1:1:1:0          yes 4971.0000 400.0000 4865.8140
  3    0      0    1 1:1:1:0          yes 4971.0000 400.0000  400.0000

Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218759
Signed-off-by: Perry Yuan 
Co-developed-by: Mario Limonciello 
Signed-off-by: Mario Limonciello 
Tested-by: Gaha Bana 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: amd-pstate: Enable amd-pstate preferred core support

2024-09-12T09:11:40+00:00

commit f3a052391822b772b4e27f2594526cf1eb103cab upstream.

amd-pstate driver utilizes the functions and data structures
provided by the ITMT architecture to enable the scheduler to
favor scheduling on cores which can be get a higher frequency
with lower voltage. We call it amd-pstate preferrred core.

Here sched_set_itmt_core_prio() is called to set priorities and
sched_set_itmt_support() is called to enable ITMT feature.
amd-pstate driver uses the highest performance value to indicate
the priority of CPU. The higher value has a higher priority.

The initial core rankings are set up by amd-pstate when the
system boots.

Add a variable hw_prefcore in cpudata structure. It will check
if the processor and power firmware support preferred core
feature.

Add one new early parameter `disable` to allow user to disable
the preferred core.

Only when hardware supports preferred core and user set `enabled`
in early parameter, amd pstate driver supports preferred core featue.

Tested-by: Oleksandr Natalenko 
Reviewed-by: Huang Rui 
Reviewed-by: Wyes Karny 
Reviewed-by: Mario Limonciello 
Co-developed-by: Perry Yuan 
Signed-off-by: Perry Yuan 
Signed-off-by: Meng Li 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: scmi: Avoid overflow of target_freq in fast switch

2024-09-08T05:54:43+00:00

[ Upstream commit 074cffb5020ddcaa5fafcc55655e5da6ebe8c831 ]

Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
can lead to overflow if the multiplied result is greater than
UINT_MAX, since type of target_freq is unsigned int. Avoid this
overflow by assigning target_freq to unsigned long variable for
converting it to HZ.

Signed-off-by: Jagadeesh Kona 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: qcom-nvmem: fix memory leaks in probe error paths

2024-08-11T10:47:14+00:00

[ Upstream commit d01c84b97f19f1137211e90b0a910289a560019e ]

The code refactoring added new error paths between the np device node
allocation and the call to of_node_put(), which leads to memory leaks if
any of those errors occur.

Add the missing of_node_put() in the error paths that require it.

Cc: stable@vger.kernel.org
Fixes: 57f2f8b4aa0c ("cpufreq: qcom: Refactor the driver to make it easier to extend")
Signed-off-by: Javier Carrasco 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: qcom-nvmem: Simplify driver data allocation

2024-08-11T10:47:13+00:00

[ Upstream commit 2a5d46c3ad6b0e62d2b04356ad999d504fb564e0 ]

Simplify the allocation and cleanup of driver data by using devm
together with a flexible array. Prepare for adding additional per-CPU
data by defining a struct qcom_cpufreq_drv_cpu instead of storing the
opp_tokens directly.

Signed-off-by: Stephan Gerhold 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Viresh Kumar 
Stable-dep-of: d01c84b97f19 ("cpufreq: qcom-nvmem: fix memory leaks in probe error paths")
Signed-off-by: Sasha Levin

cpufreq/amd-pstate: Fix the scaling_max_freq setting on shared memory CPPC systems

2024-08-03T06:53:34+00:00

[ Upstream commit 738d7d03571c7e38565bd245c0815a2c74665018 ]

On shared memory CPPC systems, with amd_pstate=active mode, the change
in scaling_max_freq doesn't get written to the shared memory
region. Due to this, the writes to the scaling_max_freq sysfs file
don't take effect. Fix this by propagating the scaling_max_freq
changes to the shared memory region.

Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors")
Reported-by: David Arcari 
Signed-off-by: Dhananjay Ugwekar 
Reviewed-by: Mario Limonciello 
Link: https://lore.kernel.org/r/20240702081413.5688-3-Dhananjay.Ugwekar@amd.com
Signed-off-by: Mario Limonciello 
Signed-off-by: Sasha Levin