kernel/git/stable/linux.git/drivers/cpufreq/intel_pstate.c, branch master

cpufreq: intel_pstate: Avoid using DESIRED_PERF when DEC is enabled

2026-08-15T17:10:48+00:00

In principle, the desired performance level can be set in MSR_HWP_REQUEST to indicate to the processor what performance level the OS would like the given CPU to run at, but if the Dynamic Efficiency Control (DEC) feature is enabled in the processor, doing so may result in confusing the processor firmware. It is then better to let the processor firmware figure out the most suitable performance level by itself. Accordingly, make intel_pstate always set the desired performance level to zero (which means "no preference") when running on a platform with DEC enabled. Signed-off-by: Rafael J. Wysocki Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/4758098.LvFx2qVVIh@rafael.j.wysocki

cpufreq: intel_pstate: Consolidate HWP P-states initialization

2026-08-15T17:08:20+00:00

After previous changes, intel_pstate_hybrid_hwp_adjust() does not do much and its name and kerneldoc comment (which is not really necessary because the function is static) have become a bit confusing. Moreover, the initialization of P-states on systems with HWP enabled is divided between it and a direct conditional statement branch in intel_pstate_get_cpu_pstates() which is not super-easy to follow. Address this by introducing intel_pstate_get_hwp_pstates() for the entire HWP-specific initialization of P-states and moving the code from intel_pstate_hybrid_hwp_adjust() into it along with some HWP-related code from intel_pstate_get_cpu_pstates(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/6021518.DvuYhMxLoT@rafael.j.wysocki

cpufreq: intel_pstate: Adjust policy->cur in active mode to policy

2026-07-31T17:35:39+00:00

Since arch_freq_get_on_cpu() on x86 falls back to cpufreq_quick_get(), which effectively causes policy->cur to be returned when intel_pstate is used, adjust intel_pstate_set_policy() to set policy->cur to reflect the P-state that is actually going to be requested in the "performance" policy case instead of setting it to policy->min (which is confusing because it causes scaling_cur_freq to show the minimum frequency while the CPU is likely running at the maximum one). For this purpose, rearrange intel_pstate_set_policy() to handle the HWP case separately, to avoid calling intel_pstate_set_pstate() pointlessly with HWP enabled, and use the observation that with HWP enabled in the active mode, the utilization update hook is only needed when HWP boost is used and the policy is not "performance". Signed-off-by: Rafael J. Wysocki Reviewed-by: Doug Smythies Tested-by: Doug Smythies Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/5144014.31r3eYUQgx@rafael.j.wysocki

Merge back cpufreq material for 7.3

2026-07-16T13:50:17+00:00

cpufreq: intel_pstate: Move two functions closer to callers

2026-07-15T15:46:40+00:00

Move intel_pstate_set_pstate() and intel_pstate_set_min_pstate() closer to their first callers. No intentional functional impact. Signed-off-by: Rafael J. Wysocki [ rjw: Changelog adjustment ] Link: https://patch.msgid.link/3433588.44csPzL39Z@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Consolidate frequency values computation

2026-07-15T15:46:40+00:00

Update intel_pstate_get_cpu_pstates() to use intel_pstate_update_freq_limits() for computing the max and turbo frequency values in all cases, including non-hybrid HWP and HWP disabled. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3059329.e9J7NaK4W3@rafael.j.wysocki

cpufreq: intel_pstate: Introduce intel_pstate_update_freq_limits()

2026-07-15T15:46:40+00:00

Introduce a new helper function, intel_pstate_update_freq_limits(), for updating the max and turbo frequency values for the given CPU after updating the corresponding P-states. Use it in intel_pstate_get_hwp_cap() and intel_pstate_get_cpu_pstates(), in the latter case instead of the direct updates of the max and turbo frequency values in intel_pstate_hybrid_hwp_adjust(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2277328.irdbgypaU6@rafael.j.wysocki

cpufreq: intel_pstate: Fix setting minimum P-state at init time

2026-07-15T15:46:40+00:00

If HWP is enabled, writes to MSR_IA32_PERF_CTL have no effect, so intel_pstate_get_cpu_pstates() should not attempt to call intel_pstate_set_min_pstate() to set the minimum P-state for the given CPU in that case. Accordingly, remove the intel_pstate_set_min_pstate() call from intel_pstate_get_cpu_pstates() and make both intel_pstate_cpu_init() and intel_cpufreq_cpu_init() call that function in their non-HWP code paths. The HWP code path in intel_pstate_cpu_init() does not need to update the current P-state of the CPU directly at all because it is taken care of the processor automatically, but the HWP code path of intel_cpufreq_cpu_init() should update it in principle to initialize the DESIRED_PERF field in MSR_HWP_REQUEST. For this purpose, make it call intel_cpufreq_hwp_update() and pass the minimum P-state limit to it as the current target value along with the current minimum and maximum limits. Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5090465.GXAFRqVoOG@rafael.j.wysocki

cpufreq: intel_pstate: Rename INTEL_PSTATE_HWP_BROADWELL

2026-07-15T15:46:40+00:00

Since the only role of INTEL_PSTATE_HWP_BROADWELL is to indicate that hybrid HWP should not be used, rename it to INTEL_PSTATE_HWP_NOT_HYBRID. No functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3431755.44csPzL39Z@rafael.j.wysocki

cpufreq: intel_pstate: Simplify HWP handling on Broadwell

2026-07-15T15:46:40+00:00

After commit de5bcf404ace ("cpufreq: intel_pstate: Clean up frequency computations"), the Broadwell HWP mode does not actually do anything useful because intel_pstate_get_hwp_cap() is called in intel_pstate_verify_cpu_policy() without checking the Broadwell mode and it overrides the initial turbo and max pstate values read from MSR_PLATFORM_INFO (the minimum P-state value still comes from MSR_PLATFORM_INFO if HWP is used even without the Broadwell mode). Moreover, hwp_cap_cached is used in some places for updating MSR_HWP_REQUEST without checking the Broadwell mode either. Effectively, the only difference made by the Broadwell HWP mode is skipping the hybrid initialization which may as well be achieved by avoiding to set pstate_funcs.get_cpu_scaling on Broadwell. Link: https://sashiko.dev/#/patchset/6005456.DvuYhMxLoT%40rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3057514.e9J7NaK4W3@rafael.j.wysocki