JIRA: https://redhat.atlassian.net/browse/RHEL-222582
Upstream Status: RHEL-Only
This reverts commit 9216f15650.
Commit 9216f15650 reverted a
commit that caused a performance regression on some Intel
Jasper Lake systems. Reverting that commit caused a different
performance regression on some other systems. On balance,
we would prefer that those other systems have better performance
even if some Jasper Lake systems suffer worse performance.
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176381
commit df6e4ab654dc482c1d45776257a62ac10e14086c
Author: Sumit Gupta <sumitg@nvidia.com>
Date: Thu Feb 26 17:29:11 2026 +0530
The counters_read_on_cpu() function warns when called with IRQs
disabled to prevent deadlock in smp_call_function_single(). However,
this warning is spurious when reading counters on the current CPU,
since no IPI is needed for same CPU reads.
Commit 12eb8f4fff24 ("cpufreq: CPPC: Update FIE arch_freq_scale in
ticks for non-PCC regs") changed the CPPC Frequency Invariance Engine
to read AMU counters directly from the scheduler tick for non-PCC
register spaces (like FFH), instead of deferring to a kthread. This
means counters_read_on_cpu() is now called with IRQs disabled from the
tick handler, triggering the warning.
Fix this by restructuring the logic: when IRQs are disabled (tick
context), call the function directly for same-CPU reads. Otherwise
use smp_call_function_single().
Fixes: 997c021abc6e ("cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regs")
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit cc764d3bbd545d7d6f5f66ac678ffc522d75f0f9
Author: Pengjie Zhang <zhangpengjie2@huawei.com>
Date: Wed, 28 Jan 2026 22:24:32 +0000
According to the Linux kernel ABI documentation for 'scaling_setspeed':
"It returns the last frequency requested by the governor (in kHz) or
can be written to in order to set a new frequency for the policy."
However, the current implementation of show_speed() returns 'policy->cur'.
'policy->cur' represents the frequency after the driver has
resolved the request against the hardware frequency table and applied
policy limits (min/max).
This creates a discrepancy between the documentation/user expectation
and the actual code behavior. For instance:
1. User writes a value to 'scaling_setspeed' that is not in the OPP
table (e.g., user asks for A, driver rounds it to B).
2. User reads 'scaling_setspeed'.
3. Code returns B ('policy->cur').
4. User expects A (the "frequency requested"), but gets B.
This patch changes show_speed() to return 'userspace->setspeed', which
stores the actual value last requested by the user. This restores the
read/write symmetry of the attribute and aligns the code with the ABI
description.
The effective frequency can still be observed via 'scaling_cur_freq' or
'cpuinfo_cur_freq', preserving the distinction between "what was
requested" (setspeed) and "what is effective" (cur_freq).
Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: lihuisong@huawei.com
Link: https://patch.msgid.link/20260116094623.2980031-1-zhangpengjie2@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 0b7fbf9333fa4699a53145bad8ce74ea986caa13
Author: Felix Gu <ustc.gu@gmail.com>
Date: Tue, 27 Jan 2026 11:21:24 +0000
When calling of_parse_phandle_with_args(), the caller is responsible
to call of_node_put() to release the reference of device node.
In scmi_cpu_domain_id(), it does not release the reference.
Fixes: e336baa419 ("cpufreq: scmi: Prepare to move OF parsing of domain-id to cpufreq")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit dea8bfea76e4bea9f727f777604d4053d7e9cd92
Author: Dhruva Gole <d-gole@ti.com>
Date: Tue, 27 Jan 2026 11:21:23 +0000
Add CPUFreq support for the AM62L3 SoC with the appropriate
AM62L3 speed grade constants according to the datasheet [1].
This follows the same architecture-specific implementation pattern
as other TI SoCs in the AM6x family.
While at it, also sort instances where the SOC family names
were not sorted alphabetically.
[1] https://www.ti.com/lit/pdf/SPRSPA1
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 945fc28a06a1d30315ca416167754e10208024a5
Author: Dhruva Gole <d-gole@ti.com>
Date: Tue, 27 Jan 2026 11:21:23 +0000
Add AM62L3 SoC to the dt-platdev blocklist to ensure proper handling
of CPUFreq functionality. The AM62L3 will use its native TI CPUFreq
driver implementation instead of the generic dt-platdev driver.
This follows the same pattern as other TI SoCs like AM62A7, AM62D2,
and AM62P5 which have been previously added to this blocklist.
Reviewed-by: Kendall Willis <k-willis@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 8c376f337a7e31c42949247e24eaad9a30d6c62c
Author: Sergey Shtylyov <s.shtylyov@auroraos.dev>
Date: Tue, 27 Jan 2026 11:21:23 +0000
SCMI stands for System Control and Management Interface, not System Control
and Power Interface -- apparently, Sudeep Holla copied this line from his
SCPI driver and then just forgot to update the acronym explanation... :-)
Fixes: 99d6bdf338 ("cpufreq: add support for CPU DVFS based on SCMI message protocol")
Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 997c021abc6eb9cf7df39fa77fa5e666ad55e3a3
Author: Jie Zhan <zhanjie9@hisilicon.com>
Date: Tue, 27 Jan 2026 11:21:23 +0000
Currently, the CPPC Frequency Invariance Engine (FIE) is invoked from the
scheduler tick but defers the update of arch_freq_scale to a separate
thread because cppc_get_perf_ctrs() would sleep if the CPC regs are in PCC.
However, this deferred update mechanism is unnecessary and introduces extra
overhead for non-PCC register spaces (e.g. System Memory or FFH), where
accessing the regs won't sleep and can be safely performed from the tick
context.
Furthermore, with the CPPC FIE registered, it throws repeated warnings of
"cppc_scale_freq_workfn: failed to read perf counters" on our platform with
the CPC regs in System Memory and a power-down idle state enabled. That's
because the remote CPU can be in a power-down idle state, and reading its
perf counters returns 0. Moving the FIE handling back to the scheduler
tick process makes the CPU handle its own perf counters, so it won't be
idle and the issue would be inherently solved.
To address the above issues, update arch_freq_scale directly in ticks for
non-PCC regs and keep the deferred update mechanism for PCC regs.
Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 7e3debb4c72fe840d60014192cf93950871fb3be
Author: Pei Xiao <xiaopei01@kylinos.cn>
Date: Tue, 27 Jan 2026 11:21:22 +0000
The of_device_id table is expected to be NULL-terminated. Without the
sentinel, the traversal of the array can lead to out-of-bound access,
causing undefined behavior.
This adds the missing sentinel to the qcom_cpufreq_ipq806x_match_list
array.
Fixes: 58f5d39d5ed8 ("cpufreq: qcom-nvmem: add compatible fallback for ipq806x for no SMEM")
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176381
commit 82b6c1b542ea0530318c6f2a880d884eb4dce49f
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Mon Mar 2 17:29:05 2026 +0100
Currently, there are two helpers to match the root compatible value
against an of_device_id array:
- of_machine_device_match() returns true if a match is found,
- of_machine_get_match_data() returns the match data if a match is
found.
However, there is no helper that returns the actual of_device_id
structure corresponding to the match, leading to code duplication in
various drivers.
Fix this by reworking of_machine_device_match() to return the actual
match structure, and renaming it to of_machine_get_match().
Retain the old of_machine_device_match() functionality using a cheap
static inline wrapper around the new of_machine_get_match() helper.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/14e1c03d443b1a5f210609ec3a1ebbaeab8fb3d9.1772468323.git.geert+renesas@glider.be
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176381
commit 4a93adcbd201aad5ba607810cfe1b19d44e5d171
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date: Wed Nov 12 11:28:46 2025 +0100
Several drivers duplicate same code for getting reference to the root
node, matching it against 'struct of_device_id' table and getting out
the match data from the table entry.
There is a of_machine_compatible_match() wrapper but it takes array of
strings, which is not suitable for many drivers since they want the
driver data associated with each compatible.
Add two wrappers, similar to existing of_device_get_match_data():
1. of_machine_device_match() doing only matching against 'struct
of_device_id' and returning bool.
2. of_machine_get_match_data() doing the matching and returning
associated driver data for found compatible.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-1-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit c3852d2ca46503c00866d8eea5e18bb67d981f9b
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Fri, 21 Nov 2025 10:21:13 +0000
If CONFIG_OF is not enabled, of_match_node() is set as NULL and
qcom_cpufreq_ipq806x_match_list won't be used causing a compilation
warning.
Flag qcom_cpufreq_ipq806x_match_list as __maybe_unused to fix the
compilation warning.
While at it also flag as __initconst as it's used only in probe contest
and can be freed after probe.
This follows the pattern of the usual of_device_id variables.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511202119.6zvvFMup-lkp@intel.com/
Fixes: 58f5d39d5ed8 ("cpufreq: qcom-nvmem: add compatible fallback for ipq806x for no SMEM")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
[ Viresh: Drop __initconst ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 47c303ba6e8090f5941cc264bf207ccbda13586c
Author: Marco Crivellari <marco.crivellari@suse.com>
Date: Mon, 10 Nov 2025 16:18:48 +0000
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
[ Viresh: Fixed Subject ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 58f5d39d5ed8f2e43f230389ea0d59791afdcd55
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Mon, 10 Nov 2025 16:16:52 +0000
On some IPQ806x SoC SMEM might be not initialized by SBL. This is the
case for some Google devices (the OnHub family) that can't make use of
SMEM to detect the SoC ID (and socinfo can't be used either as it does
depends on SMEM presence).
To handle these specific case, check if the SMEM is not initialized (by
checking if the qcom_smem_get_soc_id returns -ENODEV) and fallback to
OF machine compatible checking to identify the SoC variant.
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 1971b18785d198ae5adbb861136ae5c0f195c14d
Author: Jie Zhan <zhanjie9@hisilicon.com>
Date: Tue, 28 Oct 2025 10:40:47 +0000
During the CPPC FIE initialization, reading perf counters on offline cpus
should be expected to fail. Don't warn on this case.
Also, change the error log level to debug since FIE is optional.
Co-developed-by: Bowen Yu <yubowen8@huawei.com>
Signed-off-by: Bowen Yu <yubowen8@huawei.com> # Changing loglevel to debug
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
[ Viresh: Added back the dropped comment. ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 9600156bb99852c216a2128cdf9f114eb67c350f
Author: Miaoqian Lin <linmq006@gmail.com>
Date: Tue, 28 Oct 2025 10:28:13 +0000
There are two reference count leaks in this driver:
1. In nforce2_fsb_read(): pci_get_subsys() increases the reference count
of the PCI device, but pci_dev_put() is never called to release it,
thus leaking the reference.
2. In nforce2_detect_chipset(): pci_get_subsys() gets a reference to the
nforce2_dev which is stored in a global variable, but the reference
is never released when the module is unloaded.
Fix both by:
- Adding pci_dev_put(nforce2_sub5) in nforce2_fsb_read() after reading
the configuration.
- Adding pci_dev_put(nforce2_dev) in nforce2_exit() to release the
global device reference.
Found via static analysis.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 85976d3774be8fe290eb0468c1b0a0c36f40cbfe
Author: Aaron Kling <webgeek1234@gmail.com>
Date: Thu, 23 Oct 2025 12:10:11 +0000
Add support to use OPP table from DT in Tegra186 cpufreq driver.
Tegra SoC's receive the frequency lookup table (LUT) from BPMP-FW.
Cross check the OPP's present in DT against the LUT from BPMP-FW
and enable only those DT OPP's which are present in LUT also.
The OPP table in DT has CPU Frequency to bandwidth mapping where
the bandwidth value is per MC channel. DRAM bandwidth depends on the
number of MC channels which can vary as per the boot configuration.
This per channel bandwidth from OPP table will be later converted by
MC driver to final bandwidth value by multiplying with number of
channels before being handled in the EMC driver.
If OPP table is not present in DT, then use the LUT from BPMP-FW
directly as the CPU frequency table and not do the DRAM frequency
scaling which is same as the current behavior.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
[ Viresh: Fix _free() definitions ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 2de5cb96060a1664880d65b120e59485a73588a8
Author: Shuhao Fu <sfual@cse.ust.hk>
Date: Thu, 23 Oct 2025 12:10:11 +0000
In function `s5pv210_cpu_init`, a possible refcount inconsistency has
been identified, causing a resource leak.
Why it is a bug:
1. For every clk_get, there should be a matching clk_put on every
successive error handling path.
2. After calling `clk_get(dmc1_clk)`, variable `dmc1_clk` will not be
freed even if any error happens.
How it is fixed: For every failed path, an extra goto label is added to
ensure `dmc1_clk` will be freed regardlessly.
Signed-off-by: Shuhao Fu <sfual@cse.ust.hk>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 6db0f533d320fab54154b0207e9df108427dd939
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Mon, 20 Oct 2025 21:01:35 +0000
During S3/S4 suspend and resume, cpufreq policies are not freed or
recreated; the freq_table and policy structure remain intact. However,
set_freq_table_sorted() currently resets policy->freq_table_sorted to
UNSORTED unconditionally, which is unnecessary since the table order
does not change across suspend/resume.
This patch adds a check to skip validation if policy->freq_table_sorted
is already ASCENDING or DESCENDING. This avoids unnecessary traversal
of the frequency table on S3/S4 resume or repeated online events,
reducing overhead while preserving correctness.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Link: https://patch.msgid.link/20251011072420.11495-1-zhangzihuan@kylinos.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit ba6018929165fc914c665f071f8e8cdbac844a49
Author: Aaron Kling <webgeek1234@gmail.com>
Date: Mon, 29 Sep 2025 14:55:50 +0000
During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
are still at reset values and not reflecting the actual frequency. This
causes get calls to fail. Set all cores to their respective max
frequency during probe to initialize the registers to working values.
Suggested-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 0b1bb980fd7cae126ee3d59f817068a13e321b07
Author: Aaron Kling <webgeek1234@gmail.com>
Date: Mon, 29 Sep 2025 14:55:35 +0000
The original commit set all cores in a cluster to a shared policy, but
did not update set_target to apply a frequency change to all cores for
the policy. This caused most cores to remain stuck at their boot
frequency.
Fixes: be4ae8c19492 ("cpufreq: tegra186: Share policy per cluster")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 9a1aa642c1fb5a3776447182aaf37dfaafb36134
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Tue, 23 Sep 2025 17:16:56 +0000
The cpufreq documentation suggests avoiding direct pointer subtraction
when working with entries in driver_freq_table, as it is relatively
costly. Instead, the recommended approach is to use the provided
iteration macros, like cpufreq_for_each_valid_entry_idx().
Use cpufreq_for_each_entry_idx() instead of pointer subtraction in
cpufreq_frequency_table_cpuinfo() which improves code clarity and
follows the established cpufreq coding style.
While at it, remove redundant local variable initialization from
cpufreq_table_index_unsorted().
No functional change intended.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Link: https://patch.msgid.link/20250923075553.45532-1-zhangzihuan@kylinos.cn
[ rjw: Subject tweak, changelog edits, local variable definition tweak ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 7c0dde86c17665cb27e1c8dd23d263e2ed2d5b50
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Fri, 19 Sep 2025 23:11:44 +0000
Currently, cpufreq allows drivers to implement both ->target() and
->target_index() callbacks, but that can lead to ambiguous or incorrect
behavior.
For this reason, prevent cpufreq drivers implementing both ->target()
and ->target_index() at the same time from registering.
This check can help to catch driver implementation mistakes early and
improve overall robustness, without affecting existing valid drivers.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Link: https://patch.msgid.link/20250908085738.31602-1-zhangzihuan@kylinos.cn
[ rjw: Subject adjustment and changelog rewrite ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 995694ef91da7076ce235f028680fb31ad0b5c04
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon, 15 Sep 2025 21:43:31 +0000
Make drv_write() call on_each_cpu_mask() instead of using an open-coded
equivalent of the latter.
Also remove a comment mentioning the smp_call_function_many() usage
which is not particularly useful anyway.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 97248d05b70edc674f2f2fa835fed33172686b1d
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Fri, 05 Sep 2025 20:16:55 +0000
Since commit e0b3165ba5 ("cpufreq: add 'freq_table' in struct
cpufreq_policy"), freq_table has been stored in struct cpufreq_policy
instead of being maintained separately.
However, several helpers in freq_table.c still take both policy and
freq_table as parameters, even though policy->freq_table can always be
used. This leads to redundant function arguments and increases the
chance of inconsistencies.
This patch removes the unnecessary freq_table argument from these
functions and updates their callers to only pass policy. This makes
the code simpler, more consistent, and avoids duplication.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/20250902073323.48330-1-zhangzihuan@kylinos.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 3e681899cc6e6c77eca55dd8c7cc57b27868e8a2
Author: Liao Yuanhong <liaoyuanhong@vivo.com>
Date: Thu, 04 Sep 2025 10:20:44 +0000
While 'if (i <= 0) ... else if (i > 0) ...' is technically equivalent to
'if (i <= 0) ... else ...', the latter is vastly easier to read because
it avoids writing out a condition that is unnecessary. Let's drop such
unnecessary conditions.
Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 7bc0084632dda2907ff1d021dff36ffbdd83468c
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Fri, 29 Aug 2025 11:59:04 +0000
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
annotation for policy references. This reduces the risk of reference
counting mistakes and aligns the code with the latest kernel style.
No functional change intended.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
[ Viresh: Minor changes ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 4aeda901d6896344c5b0b3a8428c4a830007ea85
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Fri, 29 Aug 2025 11:47:36 +0000
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
annotation for policy references. This reduces the risk of reference
counting mistakes and aligns the code with the latest kernel style.
No functional change intended.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
[ Viresh: Minor changes ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 95102e0cc15688ddffc8da1f15cfec2276fa45e5
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Fri, 29 Aug 2025 11:42:24 +0000
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
annotation for policy references. This reduces the risk of reference
counting mistakes and aligns the code with the latest kernel style.
No functional change intended.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
[ Viresh: Minor changes ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit c8dc2368b23e1a9f11be4c941e13f3985195d0c9
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Fri, 29 Aug 2025 11:33:57 +0000
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
annotation for policy references. This reduces the risk of reference
counting mistakes and aligns the code with the latest kernel style.
No functional change intended.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
[ Viresh: Minor changes ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit eaa9c1f31aef4d92d0ea6c9ecde33ea08733182a
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Fri, 29 Aug 2025 11:28:27 +0000
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
annotation for policy references. This reduces the risk of reference
counting mistakes and aligns the code with the latest kernel style.
No functional change intended.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
[ Viresh: Minor changes to commit log ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit e9e124501f0d7ea2caea94711efe50fe081a11ea
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Fri, 22 Aug 2025 21:33:22 +0000
Most kernel code using strncasecmp()/strncmp() passes strlen("xxx")
as the length argument. cpufreq_parse_policy() previously used
CPUFREQ_NAME_LEN (16), which is longer than the actual strings
("performance" is 11 chars, "powersave" is 9 chars).
This patch switches to strlen() for the comparison, making the
matching slightly more permissive (e.g., "powersavexxx" will now
also match "powersave"). While this is unlikely to cause functional
issues, it aligns cpufreq with common kernel style and makes the
behavior more intuitive.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/20250822070424.166795-2-zhangzihuan@kylinos.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 37f846830b510121c5364ba7bd23e3d77a83ff9b
Author: Judith Mendez <jm@ti.com>
Date: Fri, 22 Aug 2025 12:24:13 +0000
More silicon revisions are being defined for AM62x, AM62Px, and AM62ax
SoCs. These silicon may also support currently establishes OPPs, so remove
the revision limitation in ti-cpufreq and thus determine if an OPP applies
with speed grade efuse parsing.
Signed-off-by: Judith Mendez <jm@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit f8d63d7e60e8912b5ded72319c305765b0a6322f
Author: Judith Mendez <jm@ti.com>
Date: Fri, 22 Aug 2025 12:23:04 +0000
As the AM62Px SoC family matures more speed grades are being defined.
Add support for speed grades U and T which both support all currently
established OPPs.
Signed-off-by: Judith Mendez <jm@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit b5af45302ebc141662b2b60c713c9202e88c943c
Author: Paresh Bhagat <p-bhagat@ti.com>
Date: Wed, 20 Aug 2025 14:06:06 +0000
Add support for TI K3 AM62D2 SoC to read speed and revision values
from hardware and pass to OPP layer. AM62D shares the same configuations
as AM62A so use existing am62a7_soc_data.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit fa40cbe1c86b6626d548cf2eb555bee4eea7566c
Author: Paresh Bhagat <p-bhagat@ti.com>
Date: Wed, 20 Aug 2025 14:06:06 +0000
Add ti,am62d2 SoC to the blacklist as the ti-cpufreq driver will handle
creating the cpufreq-dt platform device after it completes and ensure
it is not created twice.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit c5746dc1898a1bd5518a03081dc7e380569e269d
Author: Zihuan Zhang <zhangzihuan@kylinos.cn>
Date: Tue, 19 Aug 2025 21:13:12 +0000
When a cpufreq driver registers the first policy, it may attempt to
initialize the policy governor from `last_governor`. However, this is
meaningless for the first policy instance, because `last_governor` is
only updated when policies are removed (e.g. during CPU offline).
The `last_governor` mechanism is intended to restore the previously
used governor across CPU hotplug events. For the very first policy,
there is no "previous governor" to restore, so calling
get_governor(last_governor) is unnecessary and potentially confusing.
Skip looking up `last_governor` when registering the first policy.
Instead, it directly uses the default governor after all governors
have been registered and are available.
This avoids meaningless lookups, reduces unnecessary module reference
handling, and simplifies the initial policy path.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Link: https://patch.msgid.link/20250725041450.68754-1-zhangzihuan@kylinos.cn
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 2b5066a3a19a2870f353f8783f1ee63e61b8e371
Author: Md Sadre Alam <quic_mdalam@quicinc.com>
Date: Mon, 11 Aug 2025 12:30:46 +0000
IPQ5424 have different OPPs available for the CPU based on
SoC variant. This can be determined through use of an eFuse
register present in the silicon.
Added support for ipq5424 on nvmem driver which helps to
determine OPPs at runtime based on the eFuse register which
has the CPU frequency limits. opp-supported-hw dt binding
can be used to indicate the available OPPs for each limit.
nvmem driver also creates the "cpufreq-dt" platform_device after
passing the version matching data to the OPP framework so that the
cpufreq-dt handles the actual cpufreq implementation.
Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
[ Changed '!=' based check to '==' based check ]
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 8640689f17fd550c3e89d2b47ecb02536c58baf3
Author: Christian Marangi <ansuelsmth@gmail.com>
Date: Mon, 11 Aug 2025 12:19:20 +0000
New Airoha AN7583 SoC use the same exact logic to control the CPU
frequency. Add the Device compatible to the block list for
cpufreq-dt-plat and to the Airoha CPUFreq driver compatible list.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 32e0d669f3ac9574862a64a56c9a6dff675f8600
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Date: Mon, 11 Aug 2025 12:19:03 +0000
The MT8196 SoC uses DVFS to set a desired target frequency for each CPU
core. It also uses slightly different register offsets.
Add support for it, which necessitates reworking how the mmio regs are
acquired, as mt8196 has the fdvfs register before the performance domain
registers.
I've verified with both `sysbench cpu run` and `head -c 10G \
/dev/urandom | pigz -p 8 -c - | pv -ba > /dev/null` that we don't just
get a higher reported clock frequency, but that the observed performance
also increases, by a factor of 2.64 in an 8 thread sysbench test.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogiaocchino.delregno@collabora.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 35eb6b78854d2e9671ce8ee6b735aa0114c48da8
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Date: Mon, 11 Aug 2025 12:19:02 +0000
As it stood, the mediatek cpufreq driver could get away with never
really having a private driver instance struct. This is because all data
was stored in the per-domain structs.
However, this complicates matters when actual per-instance data like the
variant struct is introduced. Instead of having a pointer to it for
every domain, have a pointer to a global "priv" struct that can be
extended over time, and rename the "data" struct to "domain" to
distinguish its purpose better.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 2f5178abb9f5164061b9cbbb5dd860f4d206b03a
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Date: Mon, 11 Aug 2025 12:19:02 +0000
While the driver could get away with having the per-compatible match
data just be an array of the reg offsets, the only thing it used it for
right now, this doesn't really allow it to be extended in any meaningful
way if some other per-variant information needs to be communicated.
In preparation of adding support for hybrid "FDVFS" for MT8196, refactor
the code to make the DT match data a struct, which currently only
contains a single member: the reg offsets. This will allow this struct
to be extended with other members for other hardware variants.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit 4a26df233266a628157d7f0285451d8655defdfc
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date: Wed, 02 Jul 2025 12:08:16 +0000
The freq_tables[] array has num_possible_cpus() elements so, to avoid an
out of bounds access, this loop should be capped at "< nb_cpus" instead
of "<= nb_cpus". The freq_tables[] array is allocated in
armada_8k_cpufreq_init().
Cc: stable@vger.kernel.org
Fixes: f525a67053 ("cpufreq: ap806: add cpufreq driver for Armada 8K")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176381
commit b1b41bc072baf7301b1ae95fe417de09a5ad47e2
Author: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 23 Jun 2025 10:53:24 +0000
An earlier patch marked one of the two CPU masks as 'static' to reduce stack
usage, but if CONFIG_NR_CPUS is large enough, the function still produces
a warning for compile testing:
drivers/cpufreq/armada-8k-cpufreq.c: In function 'armada_8k_cpufreq_init':
drivers/cpufreq/armada-8k-cpufreq.c:203:1: error: the frame size of 1416 bytes is larger than 1408 bytes [-Werror=frame-larger-than=]
Normally this should be done using alloc_cpumask_var(), but since the
driver already has a static mask and the probe function is not called
concurrently, use the same trick for both.
Fixes: 1ffec650d0 ("cpufreq: armada-8k: Avoid excessive stack usage")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-173575
commit 6ab3532b4c98f4e51969f0e5f3fc919c535f3ce1
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon Mar 9 21:54:17 2026 +0100
Commit 02c057ddefef ("ACPI: video: Convert the driver to a platform one")
switched over the ACPI video bus driver from an ACPI driver to a platform
driver, but that change introduced an unwanted and unexpected side effect.
Namely, on some systems, the ACPI device object of the ACPI video bus
device is an ACPI companion of multiple platform devices and, after
adding video_device_ids[] as an acpi_match_table to the acpi_video_bus
platform driver, all of those devices started to match that driver and
its probe callback is invoked for all of them (it fails, but it leaves
a confusing message in the log). Moreover, the MODULE_DEVICE_TABLE()
of the ACPI video driver module matches all of the devices sharing the
ACPI companion with the ACPI video bus device.
To address this, make the core ACPI device enumeration code create an
auxiliary device for the ACPI video bus device object instead of a
platform device and switch over the ACPI video bus driver (once more)
to an auxiliary driver.
Auxiliary driver generally is a better match for ACPI video bus than
platform driver, among other things because the ACPI video bus device
does not require any resources to be allocated for it during
enumeration. It also allows the ACPI video bus driver to stop abusing
device matching based on ACPI device IDs and it allows a special case
to be dropped from acpi_create_platform_device() because that function
need not worry about the ACPI video bus device any more.
Fixes: 02c057ddefef ("ACPI: video: Convert the driver to a platform one")
Reported-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Closes: https://lore.kernel.org/linux-acpi/007e3390-6b2b-457e-83c7-c794c5952018@amd.com/
Tested-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Added AUXILIARY_BUS selection to CONFIG_ACPI to fix build issue ]
[ rjw: Fixed error path in acpi_create_video_bus_device() ]
Link: https://patch.msgid.link/5986516.DvuYhMxLoT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-173575
commit 02c057ddefef592a882c5815f22630901d9ab344
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Fri Jan 2 12:53:53 2026 +0100
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI video driver to a platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/1957556.tdWV9SEqCh@rafael.j.wysocki
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176383
commit e5c9ffc6ae1bcdb1062527d611043681ac301aca
Author: Aboorva Devarajan <aboorvad@linux.ibm.com>
Date: Tue, 17 Feb 2026 15:49:02 +0000
On certain platforms (PowerNV systems without a power-mgt DT node),
cpuidle may register only a single idle state. In cases where that
single state is a polling state (state 0), the ladder governor may
incorrectly treat state 1 as the first usable state and pass an
out-of-bounds index. This can lead to a NULL enter callback being
invoked, ultimately resulting in a system crash.
[ 13.342636] cpuidle-powernv : Only Snooze is available
[ 13.351854] Faulting instruction address: 0x00000000
[ 13.376489] NIP [0000000000000000] 0x0
[ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668
Fix this by adding a bail-out in cpuidle_select() that returns state 0
directly when state_count <= 1, bypassing the governor and keeping the
tick running.
Fixes: dc2251bf98 ("cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol")
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/20260216185005.1131593-2-aboorvad@linux.ibm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176383
commit a971f984b8455db0ef23910442029cdad53bc459
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Fri, 30 Jan 2026 20:15:52 +0000
There are cases in which decisions made by the teo governor are
arguably overly conservative.
For instance, suppose that there are 4 idle states and the values of
the intercepts metric for the first 3 of them are 400, 250, and 251,
respectively. If the total sum computed in teo_update() is 1000, the
governor will select idle state 1 (provided that all idle states are
enabled and the scheduler tick has not been stopped) although arguably
idle state 0 would be a better choice because the likelihood of getting
an idle duration below the target residency of idle state 1 is greater
than the likelihood of getting an idle duration between the target
residency of idle state 1 and the target residency of idle state 2.
To address this, refine the candidate idle state lookup based on
intercepts to start at the state with the maximum intercepts metric,
below the deepest enabled one, to avoid the cases in which the search
may stop before reaching that state.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
[ rjw: Fixed typo "intercetps" in new comments (3 places) ]
Link: https://patch.msgid.link/2417298.ElGaqSPkdT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176383
commit f36de72673ad80c9931c0b411df0d6ef184f6c22
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Fri, 30 Jan 2026 20:15:43 +0000
If differences between target residency values of adjacent idle states
of a given CPU are relatively large, the corresponding idle state bins
used by the teo governors are large either and the rule by which hits
are distinguished from intercepts is inaccurate.
Namely, by that rule, a wakeup event is classified as a hit if the
sleep length (the time till the closest timer other than the tick)
and the measured idle duration, adjusted for the entered idle state
exit latency, fall into the same idle state bin. However, if that bin
is large enough, the actual difference between the sleep length and
the measured idle duration may be significant. It may in fact be
significantly greater than the analogous difference for an event where
the sleep length and the measured idle duration fall into different
bins.
For this reason, amend the rule in question with a check that will only
allow a wakeup event to be counted as a hit if the sleep length is less
than the "raw" measured idle duration (which means that the wakeup
appears to have occurred after the anticipated timer event). Otherwise,
the event will be counted as an intercept.
Also update the documentation part explaining the difference between
"hits" and "intercepts" to take the above change into account.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/5093379.31r3eYUQgx@rafael.j.wysocki
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176383
commit 80606f4eb8d7484ab7f7d6f0fd30d71e6fbcf328
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Fri, 23 Jan 2026 21:22:42 +0000
After commit 5484e31bbb ("cpuidle: menu: Skip tick_nohz_get_sleep_length()
call in some cases"), if the return value of get_typical_interval()
multiplied by NSEC_PER_USEC is not greater than RESIDENCY_THRESHOLD_NS,
the menu governor will skip computing the time till the closest timer.
If that happens when the tick has been stopped already, the selected
idle state may be too deep due to the subsequent check comparing
predicted_ns with TICK_NSEC and causing its value to be replaced with
the expected time till the closest timer, which is KTIME_MAX in that
case. That will cause the deepest enabled idle state to be selected,
but the time till the closest timer very well may be shorter than the
target residency of that state, in which case a shallower state should
be used.
Address this by making menu_select() always compute the time till the
closest timer when the tick has been stopped.
Also move the predicted_ns check mentioned above into the branch in
which the time till the closest timer is determined because it only
needs to be done in that case.
Fixes: 5484e31bbb ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/5959091.DvuYhMxLoT@rafael.j.wysocki
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176383
commit fcbd7897b871e157ee5c595e950c8466d86c0cd5
Author: Breno Leitao <leitao@debian.org>
Date: Fri, 09 Jan 2026 21:52:54 +0000
The unlikely() annotation on the early-return condition in menu_select()
is incorrect on systems with only one idle state (e.g., ARM64 servers
with a single ACPI LPI state). Branch profiling shows 100% misprediction
on such systems since drv->state_count <= 1 is always true.
On platforms where only state0 is available, this path is the common
case, not an unlikely edge case. Remove the misleading annotation to
let the branch predictor learn the actual behavior.
Signed-off-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260105-annotated_idle-v1-1-10ddf0771b58@debian.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176383
commit a4e6512a79d8486dccf3e8b066e5d6bd5ff95446
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date: Tue Nov 25 12:26:42 2025 +0100
Some platforms supports multiple low power states for CPUs that can be used
when entering system-wide suspend. Currently we are always selecting the
deepest possible state for the CPUs, which can break the system wakeup
latency constraint that may be required for a use case.
Let's take the first step towards addressing this problem, by introducing
an interface for user space, that allows us to specify the CPU system
wakeup QoS limit. Subsequent changes will start taking into account the new
QoS limit.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Kevin Hilman (TI) <khilman@baylibre.com>
Tested-by: Kevin Hilman (TI) <khilman@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/20251125112650.329269-2-ulf.hansson@linaro.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176383
Upstream Status: RHEL-only
Enable to the new interface that allows users to specify a
CPU system wakeup limit. This will allow users to decide if
they want maximum power savings with deep sleep states or
they would prefer less power savings but also less latency.
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-176383
commit d834e68a0e8b4a3c673eb96d4d53e48f3c19a81e
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Thu, 20 Nov 2025 16:32:48 +0000
Simplify the loop looking up a candidate idle state in the case when an
intercept is likely to occur by adding a search for the state index limit
if the tick is stopped before it.
First, call tick_nohz_tick_stopped() just once and if it returns true,
look for the shallowest state index below the current candidate one with
target residency at least equal to the tick period length.
Next, simply look for a state that is not shallower than the one found
in the previous step and satisfies the intercepts majority condition (if
there are no such states, the shallowest state that is not shallower
than the one found in the previous step becomes the new candidate).
Since teo_state_ok() has no callers any more after the above changes,
drop it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
[ rjw: Changelog clarification and code comment edit ]
Link: https://patch.msgid.link/2418792.ElGaqSPkdT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
Mark Langsdorf