Linux Power Management development
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: Marco Scardovi <scardracs@disroot.org>,
	K Prateek Nayak <kprateek.nayak@amd.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	perry.yuan@amd.com, rafael@kernel.org, ray.huang@amd.com,
	stuartmeckle@gmail.com, viresh.kumar@linaro.org,
	wyes.karny@amd.com
Subject: Re: [PATCH v3 1/1] cpufreq/amd-pstate: Fix EPP initialization for shared memory systems
Date: Fri, 5 Jun 2026 13:24:45 -0500	[thread overview]
Message-ID: <369d62ed-134e-42de-8263-e1a6caec76c2@amd.com> (raw)
In-Reply-To: <20260605103131.88711-2-scardracs@disroot.org>



On 6/5/26 05:26, Marco Scardovi wrote:
> At CPU initialization, the private cpudata structure is allocated via
> kzalloc, which means cpudata->cppc_req_cached is initialized to 0. This
> makes the default cached EPP value 0 (AMD_CPPC_EPP_PERFORMANCE).
> 
> When initializing a system that defaults to performance EPP, the driver
> attempts to configure the EPP via amd_pstate_set_epp(). Because the
> requested EPP (0) matches the uninitialized cached value (0), the cache
> guard check triggers, and the driver skips writing to the hardware.
> 
> On shared memory systems, the EPP write via cppc_set_epp_perf() is also
> responsible for toggling on the autonomous selection register (auto_sel).
> Skipping the EPP write consequently skips enabling auto_sel, leaving the
> CPU in non-autonomous mode. This prevents the hardware from boosting and
> leaves the CPU frequency stuck at the lowest non-linear frequency (1.7GHz).
> 
> Fix this by:
> 1. Cache the firmware programmed default EPP value in cppc_req_cached
>     during CPU EPP initialization.
> 2. Explicitly toggle the AUTO_SEL_ENABLE register to 1 during EPP CPU
>     initialization for shared memory systems, independent of whether the EPP
>     write is skipped due to a cache match.
> 
> Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221473
> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Assisted-by: Antigravity:gemini-3.5-flash
> Signed-off-by: Marco Scardovi <scardracs@disroot.org>
> ---
>   drivers/cpufreq/amd-pstate.c | 24 +++++++++++++++++++++++-
>   1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 8d55e2be825b..8e0099eba512 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -1877,6 +1877,7 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
>   	struct amd_cpudata *cpudata;
>   	union perf_cached perf;
>   	struct device *dev;
> +	s16 default_epp;

Reviewing this code I realize we have a problem with the return types.

Both possible functions return u8:

static u8 msr_get_epp(struct amd_cpudata *cpudata)
static u8 shmem_get_epp(struct amd_cpudata *cpudata)

The static call returns s16:
static inline s16 amd_pstate_get_epp(struct amd_cpudata *cpudata)

But then both shmem_get_epp and msr_get_epp can return negative integers 
on failure.

So the return type for all of them should be changed to be an integer to 
support this change.

Als othe variable used in amd_pstate_epp_cpu_init needs to be an integer 
too.

>   	int ret;
>   
>   	/*
> @@ -1926,6 +1927,27 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
>   
>   	policy->boost_supported = READ_ONCE(cpudata->boost_supported);
>   
> +	/* Cache the firmware programmed EPP */
> +	default_epp = amd_pstate_get_epp(cpudata);
> +	if (default_epp < 0) {
> +		ret = default_epp;
> +		goto free_cpudata1;
> +	}
> +	FIELD_MODIFY(AMD_CPPC_EPP_PERF_MASK, &cpudata->cppc_req_cached, default_epp);
> +
> +	/*
> +	 * Shared memory based systems may require the AUTO_SEL_ENABLE register
> +	 * to be toggled on to function correctly. Since the first call to
> +	 * amd_pstate_set_epp() may bail out early if the desired EPP is
> +	 * same as the one configured by the firmware, attempt to toggle the
> +	 * AUTO_SEL_ENABLE here, independent of EPP programming.
> +	 */
> +	if (!cpu_feature_enabled(X86_FEATURE_CPPC)) {
> +		ret = cppc_set_auto_sel(policy->cpu, 1);
> +		if (ret)
> +			pr_warn("failed to enable auto_sel for cpu %d: %d\n", policy->cpu, ret);
> +	}

This doesn't really make sense to me.  I think it's actually pointing to 
a logic error in shmem_init_perf().

I think you can just drop the call to bail in active mode and get the 
same result.

> +
>   	/*
>   	 * Set the policy to provide a valid fallback value in case
>   	 * the default cpufreq governor is neither powersave nor performance.
> @@ -1933,7 +1955,7 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
>   	if (amd_pstate_acpi_pm_profile_server() ||
>   	    amd_pstate_acpi_pm_profile_undefined()) {
>   		policy->policy = CPUFREQ_POLICY_PERFORMANCE;
> -		cpudata->epp_default_ac = cpudata->epp_default_dc = amd_pstate_get_epp(cpudata);
> +		cpudata->epp_default_ac = cpudata->epp_default_dc = default_epp;
>   		cpudata->current_profile = PLATFORM_PROFILE_PERFORMANCE;
>   	} else {
>   		policy->policy = CPUFREQ_POLICY_POWERSAVE;


      reply	other threads:[~2026-06-05 18:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05 10:26 [PATCH v3 0/1] cpufreq/amd-pstate: Fix EPP initialization for shared memory systems Marco Scardovi
2026-06-05 10:26 ` [PATCH v3 1/1] " Marco Scardovi
2026-06-05 18:24   ` Mario Limonciello [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=369d62ed-134e-42de-8263-e1a6caec76c2@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=perry.yuan@amd.com \
    --cc=rafael@kernel.org \
    --cc=ray.huang@amd.com \
    --cc=scardracs@disroot.org \
    --cc=stuartmeckle@gmail.com \
    --cc=viresh.kumar@linaro.org \
    --cc=wyes.karny@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox