Re: [PATCH 0/1] cpufreq/amd-pstate: Prevent active mode on systems without EPP support

[K Prateek Nayak]

Hello Marco,

Sorry for the late follow up on this issue.

On 6/3/2026 1:49 PM, Marco Scardovi wrote:
> Hi all,
> 
> Mario, I've made the actual changes you have requested me on bugzilla for
> https://bugzilla.kernel.org/show_bug.cgi?id=221473 . Let me know if it sits
> right with you.
> 
> Prevent the amd-pstate driver from loading in EPP-reliant "active" mode on
> systems without Collaborative Processor Performance Control (CPPC) Energy
> Performance Preference (EPP) support (such as Zen 2 and older processors).
> 
> Zen 2 and older processors do not support EPP. Loading the driver in active
> mode on these systems pins the CPU frequency to the lowest non-linear
> frequency (1.7GHz).

In the initial report on that bugzilla, for the good case, you had:

  ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq <==
  3693566
  ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver <==
  amd-pstate-epp

Which is still the active mode driver. I'm a bit confused as to how that
got to 3.7GHz. Did you do a mode switch back then?

> 
> To resolve this:
> - Unconditionally probe EPP support during driver initialization via a new
>   amd_pstate_epp_supported() helper, which queries cppc_get_epp_perf() on
>   the first online CPU.
> - Lack of ENERGY_PERF support or any error from cppc_get_epp_perf() causes
>   EPP to be treated as unsupported.

I believe even the AUTO_SEL_ENABLE path allows cppc_set_epp_perf() to
work which would have otherwise failed the driver load during
amd_pstate_epp_cpu_init().

The EPP value makes no difference in that case but there is some
interaction that seems to cap your frequency to 1.7GHz

> - Cache EPP support to avoid repeated capability checks during mode switches.
> - Fall back to passive mode at boot if EPP is unsupported.
> - Reject runtime switches to active mode with -ENODEV.
> 
> Please review and provide feedback.

I think I may know what was happening: The initial cpudata->cppc_req_cached
is all 0s and as a result, you may be hitting the early bailout in
shmem_set_epp() which skips enabling EPP mode altogether if you start off
the driver with AMD_CPPC_EPP_PERFORMANCE (EPP: 0)

If it is not too much trouble, can you try applying the following on top
of amd-pstate-fixes branch [1]:

diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 72df461e7b39..3a13ce7256e2 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -426,9 +426,6 @@ static int shmem_set_epp(struct cpufreq_policy *policy, u8 epp)
 					  epp != epp_cached);
 	}
 
-	if (epp == epp_cached)
-		return 0;
-
 	perf_ctrls.energy_perf = epp;
 	ret = cppc_set_epp_perf(cpudata->cpu, &perf_ctrls, 1);
 	if (ret) {
---

and booting the kernel with "amd_pstate=active amd_dynamic_epp=enable" in the
kernel cmdline while being plugged into the wall and check if you can hit the
boost frequency with your workload?

[1] git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/log/?h=amd-pstate-fixes

-- 
Thanks and Regards,
Prateek