[for 26.04_linux-nvidia-bos]: ACPI/cpufreq: CPPC autonomous mode and register handling improvements by jamieNguyenNVIDIA · Pull Request #381 · NVIDIA/NV-Kernels

jamieNguyenNVIDIA · 2026-04-17T19:07:54Z

Summary

Brings the CPPC autonomous-mode patch series in line with what's been
accepted upstream and what's in flight on linux-pm review, replacing the
existing v1 SAUCE auto_sel_mode patch with v2 plus the upstream
prerequisites it depends on.

16 commits over the kernel base, structured as:

10 upstream cherry-picks of the ACPI CPPC and cppc_cpufreq series
merged via linux-pm: cppc_get_perf API, FFH/SystemMemory support in
cppc_set_epp_perf, MIN/MAX_PERF in target callbacks, perf_limited
sysfs interface, cppc_perf_caps reference-performance move, the
uninitialised-ref-variable fix, and consistent cpc_read() return
value checking. Subjects:
- ACPI: CPPC: Add cppc_get_perf() API to read performance controls
- ACPI: CPPC: Warn on missing mandatory DESIRED_PERF register
- ACPI: CPPC: Extend cppc_set_epp_perf() for FFH/SystemMemory
- cpufreq: CPPC: Update cached perf_ctrls on sysfs write
- cpufreq: cppc: Update MIN_PERF/MAX_PERF in target callbacks
- ACPI: CPPC: add APIs and sysfs interface for perf_limited
- cpufreq: CPPC: Add sysfs documentation for perf_limited
- ACPI: CPPC: Move reference performance to capabilities
- ACPI: CPPC: Fix uninitialized ref variable in cppc_get_perf_caps()
- ACPI: CPPC: Check cpc_read() return values consistently
Four cpufreq-core upstream cherry-picks that the v2 SAUCE patch
depends on:
- cpufreq: Remove max_freq_req update for pre-existing policy
  (mainline 04aa9d0726cc)
- cpufreq: Add boost_freq_req QoS request (mainline 6e39ba4e5a82,
  v7 of "cpufreq: introduce boost frequency QoS")
- cpufreq: Allocate QoS freq_req objects with policy (mainline
  9266b4da051a) — switches the freq_qos_request allocation model
  from heap-allocated pointers to embedded structs in
  struct cpufreq_policy
- cpufreq/amd-pstate: Cache the max frequency in cpudata (mainline
  8cdc494013df) — caches cpudata->max_freq for reuse from
  policy->cpuinfo.max_freq
Two SAUCE backports of in-flight upstream patches, both still in
review on linux-pm:
- NVIDIA: SAUCE: cpufreq: Set policy->min and max as real QoS constraints — from
  lore/20260423084731.1090384-2-pierre.gondois@arm.com.
  Makes driver-set policy->min/max durable QoS constraints in
  cpufreq_policy_online(). Applies cleanly given the prereqs in (2).
- NVIDIA: SAUCE: cpufreq: CPPC: add autonomous mode boot parameter support — v2 from
  lore/20260424201814.230071-1-sumitg@nvidia.com.
  Adds the cppc_cpufreq.auto_sel_mode= boot parameter to engage CPPC
  autonomous mode at boot.

If either of the two in-review patches changes shape, the backport will
need a redo.

Test results

Built and runtime-tested on two arm64 systems:

DGX Spark (20-core, AUTO_SEL register supported) with
cppc_cpufreq.auto_sel_mode=1 set via modprobe.d. All 20 CPUs come up
in autonomous mode with epp=0. Verified: hotplug-durability of
scaling_max_freq while autonomous mode is active; auto_select
toggle; EPP read/write/validation; perf_limited and auto_act_window
interfaces; 100-iteration stress on auto_select / EPP /
scaling_max_freq writes; rmmod + modprobe cycle (auto_sel re-engaged
from modprobe.d). Clean.
UTSkinnyJoe (288-core, AUTO_SEL not supported). SAUCE handles
-EOPNOTSUPP cleanly. Hotplug-durability of scaling_max_freq
verified. Clean.

Static: checkpatch.pl --strict clean on all SAUCE / new commits;
x86_64 allmodconfig cpufreq drivers and arm64 defconfig with CPPC
build clean.

Test plan checklist

LP: https://bugs.launchpad.net/bugs/2131705

Add cppc_get_perf() function to read values of performance control registers including desired_perf, min_perf, max_perf, energy_perf, and auto_sel. This provides a read interface to complement the existing cppc_set_perf() write interface for performance control registers. Note that auto_sel is read by cppc_get_perf() but not written by cppc_set_perf() to avoid unintended mode changes during performance updates. It can be updated with existing dedicated cppc_set_auto_sel() API. Use cppc_get_perf() in cppc_cpufreq_get_cpu_data() to initialize perf_ctrls with current hardware register values during cpufreq policy initialization. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-2-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 658fa7b) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Add a warning during CPPC processor probe if the Desired Performance register is not supported when it should be. As per 8.4.6.1.2.3 section of ACPI 6.6 specification, "The Desired Performance Register is optional only when OSPM indicates support for CPPC2 in the platform-wide _OSC capabilities and the Autonomous Selection Enable field is encoded as an Integer with a value of 1." In other words: - In CPPC v1, DESIRED_PERF is mandatory - In CPPC v2, it becomes optional only when AUTO_SEL_ENABLE is supported This helps detect firmware configuration issues early during boot. Link: https://lore.kernel.org/lkml/9fa21599-004a-4af8-acc2-190fd0404e35@nvidia.com/ Suggested-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-3-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit b3e45fb) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Extend cppc_set_epp_perf() to write both auto_sel and energy_perf registers when they are in FFH or SystemMemory address space. This keeps the behavior consistent with PCC case where both registers are already updated together, but was missing for FFH/SystemMemory. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-4-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 38428a6) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Update the cached perf_ctrls values when writing via sysfs to keep them in sync with hardware registers: - store_auto_select(): update perf_ctrls.auto_sel - store_energy_performance_preference_val(): update perf_ctrls.energy_perf This ensures consistent cached values after sysfs writes, which complements the cppc_get_perf() initialization during policy setup. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-5-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 24ad4c6) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Update MIN_PERF and MAX_PERF registers from policy->min and policy->max in the .target() and .fast_switch() callbacks. This allows controlling performance bounds via standard scaling_min_freq and scaling_max_freq sysfs interfaces. Similar to intel_cpufreq which updates HWP min/max limits in .target(), cppc_cpufreq now programs MIN_PERF/MAX_PERF along with DESIRED_PERF. Since MIN_PERF/MAX_PERF can be updated even when auto_sel is disabled, they are updated unconditionally. Also program MIN_PERF/MAX_PERF in store_auto_select() when enabling autonomous selection so the platform uses correct bounds immediately. Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Link: https://patch.msgid.link/20260206142658.72583-6-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit ea3db45) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Add sysfs interface to read/write the Performance Limited register. The Performance Limited register indicates to the OS that an unpredictable event (like thermal throttling) has limited processor performance. It contains two sticky bits set by the platform: - Bit 0 (Desired_Excursion): Set when delivered performance is constrained below desired performance. Not used when Autonomous Selection is enabled. - Bit 1 (Minimum_Excursion): Set when delivered performance is constrained below minimum performance. These bits remain set until OSPM explicitly clears them. The write operation accepts a bitmask of bits to clear: - Write 0x1 to clear bit 0 - Write 0x2 to clear bit 1 - Write 0x3 to clear both bits This enables users to detect if platform throttling impacted a workload. Users clear the register before execution, run the workload, then check afterward - if set, hardware throttling occurred during that time window. The interface is exposed as: /sys/devices/system/cpu/cpuX/cpufreq/perf_limited Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-7-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 13c45a2) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Add ABI documentation for the Performance Limited Register sysfs interface in the cppc_cpufreq driver. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-8-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 856250b) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Currently, the `Reference Performance` register is read every time the CPU frequency is sampled in `cppc_get_perf_ctrs()`. This function is on the hot path of the cppc_cpufreq driver. Reference Performance indicates the performance level that corresponds to the Reference Counter incrementing and is not expected to change dynamically during runtime (unlike the Delivered and Reference counters). Reading this register in the hot path incurs unnecessary overhead, particularly on platforms where CPC registers are located in the PCC (Platform Communication Channel) subspace. This patch moves `reference_perf` from the dynamic feedback counters structure (`cppc_perf_fb_ctrs`) to the static capabilities structure (`cppc_perf_caps`). Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> [ rjw: Changelog adjustment ] Link: https://patch.msgid.link/20260213100935.19111-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 8505bfb) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Commit 8505bfb ("ACPI: CPPC: Move reference performance to capabilities") introduced a logical error when retrieving the reference performance. On platforms lacking the reference performance register, the fallback logic leaves the local 'ref' variable uninitialized (0). This causes the subsequent sanity check to incorrectly return -EFAULT, breaking amd_pstate initialization. Fix this by assigning 'ref = nom' in the fallback path. Fixes: 8505bfb ("ACPI: CPPC: Move reference performance to capabilities") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/all/20260310003026.GA2639793@ax162/ Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260311071334.1494960-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit be473f0) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Callers of cpc_read() ignore its return value, which can lead to using uninitialized or stale values when the read fails. Fix this by consistently checking cpc_read() return values in cppc_get_perf_caps(), cppc_get_perf_ctrs(), and cppc_get_perf(). Link: https://lore.kernel.org/lkml/48bdf87e-39f1-402f-a7dc-1a0e1e7a819d@nvidia.com/ Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Link: https://patch.msgid.link/20260318095005.2437960-1-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 0cc2497) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

github-actions · 2026-04-17T19:21:08Z

✅ Patchscan: No Missing Fixes

All cherry-picked commits have been checked — no missing upstream fixes found.

nvmochs · 2026-04-17T19:27:07Z

Confirmed w/ git range-diff that these are the same patches as PR 366 that is targeting 7.0-lts.

No issues or concerns.

Acked-by: Matthew R. Ochs <mochs@nvidia.com>

clsotog

Acked-by: Carol L Soto <csoto@nvidia.com>

nirmoy

Acked-by: Nirmoy Das <nirmoyd@nvidia.com>

policy->max_freq_req QoS constraint represents the maximal allowed frequency than can be requested. It is set by: - writing to policyX/scaling_max sysfs file - toggling the cpufreq/boost sysfs file Upon calling freq_qos_update_request(), a successful update of the max_freq_req value triggers cpufreq_notifier_max(), followed by cpufreq_set_policy() which update the requested frequency for the policy. If the new max_freq_req value is not different from the original value, no frequency update is triggered. In a specific sequence of toggling: - cpufreq/boost sysfs file - CPU hot-plugging a CPU could end up with boost enabled but running at the maximal non-boost frequency, cpufreq_notifier_max() not being triggered. The following fixed that: commit 1608f02 ("cpufreq: Fix re-boost issue after hotplugging a CPU") The following: commit dd016f3 ("cpufreq: Introduce a more generic way to set default per-policy boost flag") also fixed the issue by correctly setting the max_freq_req constraint of a policy that is re-activated. This makes the first fix unnecessary. As the original issue is fixed by another method, this patch reverts: commit 1608f02 ("cpufreq: Fix re-boost issue after hotplugging a CPU") Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260326204404.1401849-2-pierre.gondois@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 04aa9d0) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

The Power Management Quality of Service (PM QoS) allows to aggregate constraints from multiple entities. It is currently used to manage the min/max frequency of a given policy. Frequency constraints can come for instance from: - Thermal framework: acpi_thermal_cpufreq_init() - Firmware: _PPC objects: acpi_processor_ppc_init() - User: by setting policyX/scaling_[min|max]_freq The minimum of the max frequency constraints is used to compute the resulting maximum allowed frequency. When enabling boost frequencies, the same frequency request object (policy->max_freq_req) as to handle requests from users is used. As a result, when setting: - scaling_max_freq - boost The last sysfs file used overwrites the request from the other sysfs file. To avoid this, create a per-policy boost_freq_req to save the boost constraints instead of overwriting the last scaling_max_freq constraint. policy_set_boost() calls the cpufreq set_boost callback. Update the newly added boost_freq_req request from there: - whenever boost is toggled - to cover all possible paths In the existing .set_boost() callbacks: - Don't update policy->max as this is done through the qos notifier cpufreq_notifier_max() which calls cpufreq_set_policy(). - Remove freq_qos_update_request() calls as the qos request is now done in policy_set_boost() and updates the new boost_freq_req $ ## Init state scaling_max_freq:1000000 cpuinfo_max_freq:1000000 $ echo 700000 > scaling_max_freq scaling_max_freq:700000 cpuinfo_max_freq:1000000 $ echo 1 > ../boost scaling_max_freq:1200000 cpuinfo_max_freq:1200000 $ echo 800000 > scaling_max_freq scaling_max_freq:800000 cpuinfo_max_freq:1200000 $ ## Final step: $ ## Without the patches: $ echo 0 > ../boost scaling_max_freq:1000000 cpuinfo_max_freq:1000000 $ ## With the patches: $ echo 0 > ../boost scaling_max_freq:800000 cpuinfo_max_freq:1000000 Note: cpufreq_frequency_table_cpuinfo() updates policy->min and max from: A. cpufreq_boost_set_sw() \-cpufreq_frequency_table_cpuinfo() B. cpufreq_policy_online() \-cpufreq_table_validate_and_sort() \-cpufreq_frequency_table_cpuinfo() Keep these updates as some drivers expect policy->min and max to be set through B. Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260326204404.1401849-3-pierre.gondois@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 6e39ba4) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

A recent change exposed a bug in the error path: if freq_qos_add_request(boost_freq_req) fails, min_freq_req may remain a valid pointer even though it was never successfully added. During policy teardown, this leads to an unconditional call to freq_qos_remove_request(), triggering a WARN. The current design allocates all three freq_req objects together, making the lifetime rules unclear and error handling fragile. Simplify this by allocating the QoS freq_req objects at policy allocation time. The policy itself is dynamically allocated, and two of the three requests are always needed anyway. This ensures consistent lifetime management and eliminates the inconsistent state in failure paths. Reported-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Fixes: 6e39ba4 ("cpufreq: Add boost_freq_req QoS request") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Tested-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://patch.msgid.link/a293f29d841b86c51f34699c6e717e01858d8ada.1774933424.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 9266b4d) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

github-actions · 2026-04-30T19:59:24Z

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ❌ Errors found

Details

Checking 16 commits...

Cherry-pick digest:
┌──────────────┬───────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject           │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 6f438a4221d1 │ cpufreq: cppc: add autonomous mode boot param │ match      │ found   │ ok, backporter: jamien    │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 9dd0cb0bdd26 │ cpufreq: set policy->min and max as real qos  │ match      │ found   │ ok, backporter: jamien    │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 6c6e63d665ae │ [SAUCE] cpufreq/amd-pstate: cache the max fre │ N/A        │ N/A     │ superm1, jamien           │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ d59875653a6e │ 9266b4da051a                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 03d677cdc228 │ 6e39ba4e5a82                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 452912d59131 │ 04aa9d0726cc                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ c3a5e79d21f2 │ 0cc24977224a                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 7de3943df546 │ be473f0591f1                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ f3d79077ae63 │ 8505bfb4e4ec                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 41cee2357e83 │ 856250ba2e81                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b1d006a988aa │ 13c45a26635f                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ a1cf76fde511 │ ea3db45ae476                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ f60982b8dd6b │ 24ad4c6c136b                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 13a90fb9f954 │ 38428a680026                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 05aa30a46030 │ b3e45fb2db9d                                  │ match      │ match   │ preserved + jamien added  │
├──────────────┼───────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ a27bdc89b6d0 │ 658fa7b1c47a                                  │ match      │ match   │ preserved + jamien added  │
└──────────────┴───────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint results:
E: 6c6e63d665ae ("cpufreq/amd-pstate: Cache the max frequency in cpu"): not SAUCE/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)

The value of maximum frequency is fixed and never changes. Doing calculations every time based off of perf is unnecessary. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20260326193620.649441-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> (backported from commit 8cdc494) [jamien: minor context-line drift in amd-pstate.c hunks from 3-way auto-merge; +/- content is byte-identical to upstream.] Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

cpufreq_set_policy() will ultimately override the policy min/max values written in the .init() callback through: cpufreq_policy_online() \-cpufreq_init_policy() \-cpufreq_set_policy() \-/* Set policy->min/max */ Thus the policy min/max values provided are only temporary. There is an exception if CPUFREQ_NEED_INITIAL_FREQ_CHECK is set and: cpufreq_policy_online() \-cpufreq_init_policy() \-__cpufreq_driver_target() \-cpufreq_driver->target() is called. To avoid any regression, set policy->min/max in cpufreq.c if the values were not initialized. In this patch: - Setting policy->min or max value in driver .init() cb is interpreted as setting a QoS constraint. - Remove policy->min/max initialization in drivers if the values are similar to policy->cpuinfo.min_freq/max_freq. The only drivers where these values are different are: - gx-suspmod.c - cppc-cpufreq.c - longrun.c - For the cppc-cpufreq driver, the lowest non-linear freq. is used as a min QoS constraint as suggested at: https://lore.kernel.org/lkml/20260213100633.15413-1-zhangpengjie2@huawei.com/ Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> (backported from https://lore.kernel.org/lkml/20260423084731.1090384-2-pierre.gondois@arm.com/) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Add a kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable CPPC autonomous performance selection on all CPUs at system startup. When autonomous mode is enabled, the hardware automatically adjusts CPU performance based on workload demands using Energy Performance Preference (EPP) hints. When auto_sel_mode=1: - Configure all CPUs for autonomous operation on first init - Set EPP to performance preference (0x0) - Use HW min/max_perf when available; otherwise initialize from caps - Clamp desired_perf to bounds before enabling autonomous mode - Hardware controls frequency instead of the OS governor The boot parameter is applied only during first policy initialization. Skip applying it on CPU hotplug to preserve runtime sysfs configuration. This patch depends on patch [2] ("cpufreq: Set policy->min and max as real QoS constraints") so that the policy->min/max set in cppc_cpufreq_cpu_init() are not overridden by cpufreq_set_policy() during init. Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> (backported from https://lore.kernel.org/lkml/20260424201814.230071-1-sumitg@nvidia.com/) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Sumit Gupta and others added 10 commits April 17, 2026 11:27

jamieNguyenNVIDIA requested review from clsotog, nirmoy and nvmochs April 17, 2026 19:07

jamieNguyenNVIDIA self-assigned this Apr 17, 2026

clsotog approved these changes Apr 17, 2026

View reviewed changes

nirmoy approved these changes Apr 20, 2026

View reviewed changes

pierregondois and others added 3 commits April 30, 2026 12:44

jamieNguyenNVIDIA force-pushed the jamien/7.0-bos/replace_cppc branch from 3712990 to 5812989 Compare April 30, 2026 19:45

superm1 and others added 3 commits April 30, 2026 14:14

jamieNguyenNVIDIA force-pushed the jamien/7.0-bos/replace_cppc branch from 5812989 to 6f438a4 Compare April 30, 2026 21:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[for 26.04_linux-nvidia-bos]: ACPI/cpufreq: CPPC autonomous mode and register handling improvements#381

[for 26.04_linux-nvidia-bos]: ACPI/cpufreq: CPPC autonomous mode and register handling improvements#381
jamieNguyenNVIDIA wants to merge 16 commits intoNVIDIA:26.04_linux-nvidia-bosfrom
jamieNguyenNVIDIA:jamien/7.0-bos/replace_cppc

jamieNguyenNVIDIA commented Apr 17, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Apr 17, 2026

Uh oh!

nvmochs commented Apr 17, 2026

Uh oh!

clsotog left a comment

Uh oh!

nirmoy left a comment

Uh oh!

github-actions Bot commented Apr 30, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Conversation

jamieNguyenNVIDIA commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test results

Test plan checklist

Uh oh!

github-actions Bot commented Apr 17, 2026

✅ Patchscan: No Missing Fixes

Uh oh!

nvmochs commented Apr 17, 2026

Uh oh!

clsotog left a comment

Choose a reason for hiding this comment

Uh oh!

nirmoy left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Validation Report

Patchscan ✅ No Missing Fixes

PR Lint ❌ Errors found

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jamieNguyenNVIDIA commented Apr 17, 2026 •

edited

Loading

github-actions Bot commented Apr 30, 2026 •

edited

Loading