From: Srinivas Pandruvada Date: Thu, 12 Mar 2026 19:41:08 +0000 (-0700) Subject: tools/power/x86/intel-speed-select: Avoid current base freq as maximum X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ae67f582398611b9f67c06961e292e3a2612346d;p=thirdparty%2Fkernel%2Flinux.git tools/power/x86/intel-speed-select: Avoid current base freq as maximum SST-PP level change results in online/offline of CPUs with -o option. The Linux intel-pstate driver internally stores the current HWP_REQ MSR value during offline and restores them during online. It is possible that during SST-PP level change, the new HWP_CAP limits can be updated. So, when a CPU is online, the HWP_REQ MSR should be updated to new values based on HWP_CAP values. This is particularly problematic when either turbo is disabled or the current HWP_REQ value (stored before online) is less than the base frequency from the updated HWP_CAP MSR guaranteed value. If the HWP_REQ MSR is not updated, then the performance will be limited to the value before perf level change. Hence the tool updates cpufreq scaling_max_freq to the newer base_frequency value in this case. This step is not required when HWP interrupts are enabled, as the perf level change should result in a new interrupt with HWP_GUARANTEED_PERF_CHANGE_STATUS and the intel_pstate driver will update to new limits. But the tool needs to handle the case when HWP interrupts are not enabled but there is no way for the tool to know that HWP interrupts are enabled or not. So, it has to still update the scaling_max_freq. With the QOS changes in the kernel, user space writes to scaling_max_freq are treated as hard limits. So, when base frequency is increased with SST-BF enabled, the cpufreq subsystem will still not allow setting to the SST-BF high priority core frequency. So, the HWP_REQ MSR will still be capped to the user-set scaling_max_freq after SST-PP level change. To address this, instead of setting scaling_max_freq to the current HWP_CAP highest frequency, set it to the maximum integer value to set the QOS limit as unconstrained. In this case, the actual HWP_REQ maximum frequency will still be capped to HWP_CAP highest performance by the intel-pstate driver. So, it will not result in invalid HWP_REQ values. Signed-off-by: Srinivas Pandruvada --- diff --git a/tools/power/x86/intel-speed-select/isst-config.c b/tools/power/x86/intel-speed-select/isst-config.c index dd9056ddb016..652ef1f567ad 100644 --- a/tools/power/x86/intel-speed-select/isst-config.c +++ b/tools/power/x86/intel-speed-select/isst-config.c @@ -1744,6 +1744,9 @@ static int no_turbo(void) return parse_int_file(0, "/sys/devices/system/cpu/intel_pstate/no_turbo"); } +#define U32_MAX ((unsigned int)~0U) +#define S32_MAX ((int)(U32_MAX >> 1)) + static void adjust_scaling_max_from_base_freq(int cpu) { int base_freq, scaling_max_freq; @@ -1751,7 +1754,7 @@ static void adjust_scaling_max_from_base_freq(int cpu) scaling_max_freq = parse_int_file(0, "/sys/devices/system/cpu/cpu%d/cpufreq/scaling_max_freq", cpu); base_freq = get_cpufreq_base_freq(cpu); if (scaling_max_freq < base_freq || no_turbo()) - set_cpufreq_scaling_min_max(cpu, 1, base_freq); + set_cpufreq_scaling_min_max(cpu, 1, S32_MAX); } static void adjust_scaling_min_from_base_freq(int cpu)