All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lazar, Lijo" <lijo.lazar@amd.com>
To: Priya Hosur <Priya.Hosur@amd.com>,
	amd-gfx@lists.freedesktop.org, Alexander.Deucher@amd.com,
	Kevin.Wang@amd.com, Christian.Koenig@amd.com,
	Felix.Kuehling@amd.com
Cc: Veerabadhran.Gopalakrishnan@amd.com, Pratik.Vishwakarma@amd.com
Subject: Re: [PATCH v3 1/1] drm/amd/pm: restore the forced performance level after a reset
Date: Tue, 3 Nov 2026 16:11:24 +0530	[thread overview]
Message-ID: <51d3d345-e1f0-48db-af47-de488e428dcf@amd.com> (raw)
In-Reply-To: <f370dc0e7025b9b39cac723b1b60ccbd339d233f.1793689935.git.Priya.Hosur@amd.com>



On 03-Nov-26 3:58 PM, Priya Hosur wrote:
> smu_late_init() re-applies the DPM level with
> 
>    smu_handle_task(smu, smu->smu_dpm.dpm_level, AMD_PP_TASK_COMPLETE_INIT);
> 
> but smu_adjust_power_state_dynamic() only programs the hardware when
> 
>    if (force_performance_level || smu_dpm_ctx->dpm_level != level)
> 
> AMD_PP_TASK_COMPLETE_INIT passes force_performance_level = false and
> smu_dpm_ctx is &smu->smu_dpm, so the level is compared against itself and
> smu_asic_set_performance_level() is never called.
> 
> PMFW is reinitialised by a reset and comes back on its default curve, while
> smu_dpm.dpm_level still holds the level the user forced. The device then
> runs at the default level while sysfs keeps reporting the forced one. On an
> SMU 14.0.1 APU gfxclk drops from 2.8GHz to 600MHz while sysfs still reports
> high. Writing the same level again does not help either, as
> amdgpu_dpm_force_performance_level() returns early when the requested level
> matches the cached one.
> 
> amdgpu_dpm_reapply_umd_profile() restores the PROFILE_* levels after
> recovery, but returns early for any other level, so high, low and manual
> are left on the PMFW default.
> 
> Force the level to be programmed for AMD_PP_TASK_COMPLETE_INIT during reset
> recovery. The cached level is left untouched, so if programming fails the
> level the user asked for is still retained and the failure is logged.
> 
> Signed-off-by: Priya Hosur <Priya.Hosur@amd.com>
> ---
>   drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index a901f8535598..654ff6824fdd 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -2553,7 +2553,12 @@ static int smu_handle_task(struct smu_context *smu,
>   		ret = smu_adjust_power_state_dynamic(smu, level, false, false);
>   		break;
>   	case AMD_PP_TASK_COMPLETE_INIT:
> -		ret = smu_adjust_power_state_dynamic(smu, level, true, false);
> +		/*
> +		 * PMFW is reinitialised by a reset, so program the retained
> +		 * level again even though it matches the cached one.
> +		 */
> +		ret = smu_adjust_power_state_dynamic(smu, level, true,
> +						     amdgpu_reset_in_recovery(smu->adev));
>   		break;

There is already a reapply profile to handle this.

Does it work if you replace the current smu_reapply_power_state_dynamic 
by calling smu_adjust_power_state_dynamic(smu, level, true, true)?

Thanks,
Lijo

>   	case AMD_PP_TASK_READJUST_POWER_STATE:
>   		ret = smu_adjust_power_state_dynamic(smu, level, true, false);


  reply	other threads:[~2026-11-03 10:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 10:28 [PATCH v3 0/1] drm/amd/pm: restore the forced performance level after a reset Priya Hosur
2026-11-03 10:28 ` [PATCH v3 1/1] " Priya Hosur
2026-11-03 10:41   ` Lazar, Lijo [this message]
2026-11-03 10:44     ` Lazar, Lijo
2026-11-03 11:37       ` Wang, Kevin
2026-11-03 12:07         ` Lazar, Lijo

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=51d3d345-e1f0-48db-af47-de488e428dcf@amd.com \
    --to=lijo.lazar@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=Kevin.Wang@amd.com \
    --cc=Pratik.Vishwakarma@amd.com \
    --cc=Priya.Hosur@amd.com \
    --cc=Veerabadhran.Gopalakrishnan@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.