On 10/8/25 1:30 PM, Robert Beckett wrote:
---- On Tue, 07 Oct 2025 20:40:43 +0100 Mario Limonciello <[email protected]> wrote --- > On 10/7/25 2:31 PM, Bob Beckett wrote: > > --- quoted message --- > >> From: Robert Beckett <[email protected]> > >>> Lijo pointed out to me that > >>> commit ed4efe426a49 ("drm/amd: Restore cached power limit during resume") > >>> commit 796ff8a7e01b ("drm/amd: Restore cached manual clock settings during resume") > >>> both should be unnecessary because smu_restore_dpm_user_profile() already > >>> restores them. However in looking at the code there is a case that isn't > >>> properly restored - the FAST PPT limits supported by Van Gogh. The nuance > >>> isn't immediately obvious because the limit variable is overloaded with > >>> limit type. > >>> This series attempts to address that issue by passing limit type around > >>> and saving/restoring both types. > >>> Cc: Lijo Lazar <[email protected]> > >>> Mario Limonciello (5): > >>> drm/amd: Remove some unncessary header includes > >>> drm/amd: Stop overloading power limit with limit type > >>> drm/amd: Save and restore all limit types > >>> drm/amd: Drop calls to restore power limit and clock from smu_resume() > >>> drm/amd: Adjust whitespace for vangogh_ppt > >>> .../gpu/drm/amd/include/kgd_pp_interface.h | 2 +- > >>> drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 3 +- > >>> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 3 +- > >>> drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 2 +- > >>> .../gpu/drm/amd/pm/powerplay/amd_powerplay.c | 5 +-- > >>> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 40 ++++++++----------- > >>> drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +- > >>> .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 13 +++--- > >>> 8 files changed, 29 insertions(+), 42 deletions(-) > >>> -- > >>> 2.51.0 > >> entire series > >> Tested-by: Robert Beckett <[email protected]> > > > > apologies, I need to retract this Tested-by. > > I inadvertently tested v1. v2 looks like it still has the restore issue. > > I'll debug and get back to you. > > Oh thanks for getting back. Let me hold up our merge on the patches > then too. > The issue with v2 turned out to be quite simple in the end. You dropped drm/amd: Drop superfluous call to set_power_limit() from v1. picking that on top of v2 series makes it work again, so assuming v3 adds this back, have another: entire series Tested-by: Robert Beckett <[email protected]>
Lijo had commented that limits are different for default and fast PPT, so we shouldn't be dropping that. There is already a check in vangogh_set_power_limit() which is used for checking fast limits.
So to me it appears the issue here is with the handling of fast PPT. With that patch (Drop superfluous call to set_power_limit) in place do you see "New power limit (%d) is out of range" in the logs?
If not; maybe can you annotate with the v2 applied but not that "Drop superfluous call to set_power_limit" patch what each call to smu_set_power_limit() has for arguments and what max_power_limit, min_power_limit are.
I wonder if you're ending up with a call with a fast limit of 0. If so; throw a dump_stack() in that condition so we can understand why.
I see max_fast_ppt_limit is hard coded to 30 in vangogh_ppt.
