From: Priya Hosur <Priya.Hosur@amd.com>
To: <amd-gfx@lists.freedesktop.org>, <Kevin.Wang@amd.com>,
<Lijo.Lazar@amd.com>, <Christian.Koenig@amd.com>,
<Felix.Kuehling@amd.com>
Cc: <Priya.Hosur@amd.com>, <Pratik.Vishwakarma@amd.com>,
<Veerabadhran.Gopalakrishnan@amd.com>
Subject: [PATCH v4 0/1] drm/amd/pm: restore the forced performance level after a reset
Date: Wed, 4 Nov 2026 15:52:21 +0530 [thread overview]
Message-ID: <cover.1793787406.git.Priya.Hosur@amd.com> (raw)
After a GPU reset the level reported through
power_dpm_force_performance_level no longer matches the hardware. The reset
reinitialises PMFW, which comes back on its default curve, while
smu_dpm.dpm_level still holds the level the user forced. On an SMU 14.0.1
APU with the level set to high, gfxclk drops from 2.8GHz to 600MHz while
sysfs still reports high.
amdgpu_dpm_reapply_umd_profile() already replays the retained level after
reset and resume, but only for the PROFILE_* levels.
v4 follows Lijo's review of v3 and restores every level through that
common path, renamed to amdgpu_dpm_reapply_performance_level(). The
PROFILE_* levels keep their UMD pstate handling, other levels only replay
the level itself. smu_reapply_power_state_dynamic() now calls
smu_adjust_power_state_dynamic(smu, level, true, true).
Tested on an SMU 14.0.1 APU (PMFW 100.113.0) on amd-staging-drm-next,
triggering resets through debugfs/amdgpu_gpu_recover and reading the level
and gfxclk before and after each reset.
Changing smu_reapply_power_state_dynamic() alone does not restore high, as
the reapply path returns early for it:
level before reset 1 reset 2 reset 3
high 2448MHz 630MHz 600MHz 600MHz
With this patch:
level before reset 1 reset 2 reset 3
high 2444MHz 2794MHz 2796MHz 2796MHz
low 1403MHz 604MHz 600MHz 600MHz
manual 600MHz 600MHz 600MHz 600MHz
profile_peak 1848MHz 2237MHz 2019MHz 2318MHz
profile_standard 1265MHz 703MHz 700MHz 700MHz
auto 637MHz 600MHz 600MHz 600MHz
The level is retained across every reset. The "before" sample is taken one
second after the level is written. 18 MODE2 resets over the run, with no
new messages in the kernel log.
As the reapply path also runs on resume, s2idle was checked as well: high
2668MHz before suspend and 2799MHz after resume, profile_peak 2508MHz
before and 2266MHz after, with the level retained in both cases.
Notes:
- auto is not replayed, as PMFW comes back in auto after a reset, as it
does at probe. This also keeps the probe path, which runs the same
function, unchanged.
- Replaying manual does not program any clocks. The user clock masks set
in manual are restored by smu_restore_dpm_user_profile(), which only
runs on resume; restoring them after a reset is not part of this patch.
- Only the swSMU path was tested. The powerplay path takes the same
route through pp_dpm_reapply_performance_level() but I have no
hardware to test it on, nor S3 or runtime PM resume.
v4:
- Restore the level through the common reapply path instead of
smu_handle_task(), so the level is restored in one place (Lijo)
- Rename amdgpu_dpm_reapply_umd_profile() to
amdgpu_dpm_reapply_performance_level() and replay non-profile levels
directly (Lijo)
- Replace the body of smu_reapply_power_state_dynamic() with
smu_adjust_power_state_dynamic(smu, level, true, true) (Lijo)
- Add the Fixes tag (Kevin)
- Add the version changelog to the commit message
- Kevin's Reviewed-by on v3 is not carried over, as it was given for
his suggested change in smu_handle_task(), which v4 does not use
- Add test results for the smu_reapply_power_state_dynamic() change alone
- Link: https://lore.kernel.org/amd-gfx/cover.1793689935.git.Priya.Hosur@amd.com/
v3:
- Use the existing force_performance_level argument of
smu_adjust_power_state_dynamic() for AMD_PP_TASK_COMPLETE_INIT during
reset recovery, instead of switching the cached level to AUTO first
- Rebased on amd-staging-drm-next, which now includes Kevin's
"drm/amd/pm: reapply umd profile state after recovery"
- Explain in the commit message why that path does not cover high,
low and manual (Kevin's question on v2)
v2:
- Restore the forced level after the reset instead of reporting the
default, as the driver is expected to keep the level the user asked
for and the reset often goes unnoticed (Lijo)
- Link: https://lore.kernel.org/amd-gfx/20261008104026.4102222-1-Priya.Hosur@amd.com/
v1:
- Reset the cached level to AUTO after a reset so that sysfs reports the
level PMFW is actually running at
- Link: https://lore.kernel.org/amd-gfx/20261007122103.4019578-1-Priya.Hosur@amd.com/
Priya Hosur (1):
drm/amd/pm: restore the forced performance level after a reset
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +--
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 21 +++++++++---
drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 2 +-
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 39 ++++------------------
4 files changed, 26 insertions(+), 40 deletions(-)
--
2.43.0
next reply other threads:[~2026-11-04 10:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 10:22 Priya Hosur [this message]
2026-11-04 10:22 ` [PATCH v4 1/1] drm/amd/pm: restore the forced performance level after a reset Priya Hosur
2026-11-05 6:00 ` 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=cover.1793787406.git.Priya.Hosur@amd.com \
--to=priya.hosur@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=Felix.Kuehling@amd.com \
--cc=Kevin.Wang@amd.com \
--cc=Lijo.Lazar@amd.com \
--cc=Pratik.Vishwakarma@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.