AMD General > -----Original Message----- > From: Lazar, Lijo <[email protected]> > Sent: Monday, August 31, 2026 7:06 PM > To: Wang, Kevin <[email protected]>; [email protected] > Cc: Deucher, Alexander <[email protected]>; Zhang, Hawking > <[email protected]>; Feng, Kenneth <[email protected]> > Subject: Re: [PATCH 0/7] drm/amd/pm: stage OD reset until commit > > > > On 31-Aug-26 4:25 PM, Lazar, Lijo wrote: > > > > > > On 31-Aug-26 10:05 AM, Kevin Wang wrote: > >> [Some people who received this message don't often get email from > >> [email protected]. Learn why this is important at https://aka.ms/ > >> LearnAboutSenderIdentification ] > >> > >> The pp_od_clk_voltage interface exposes a staged OverDrive workflow: > >> users edit clock, voltage, and power settings, then write "c" to > >> commit them to the SMU. > >> > >> However, PP_OD_RESTORE_DEFAULT_TABLE does not follow this workflow > on > >> every SMU version. Some backends restore their cached settings and > >> wait for "c", while others upload the reset table or send > >> frequency-limit commands directly from "r". As a result, the same > >> userspace sequence has different hardware effects across ASICs. > >> > >> For example: > >> > >> - SMU 14.0.0 and SMU 13.0.5 stage reset limits until "c". > >> - SMU 14.0.2 and SMU 13.0.6 apply reset values immediately. > >> - Navi10 stages the boot OD table, while Vega20 reads the current SMU > >> table instead of restoring the saved defaults. > >> > >> This series makes "r" restore default values only in driver-side > >> staging state. "c" remains the sole operation that uploads an OD > >> table or sends frequency-limit commands to PMFW. > >> > >> This gives pp_od_clk_voltage one consistent transaction model: > >> > >> edit/reset -> staged driver state -> commit > > > > Reset should be reset to defaults and shouldn't require extra commit. > > This breaks existing userspace for SMU 13.0.6. > > > > I see that this breaks existing userspace for almost all of it. SMU > 13.0.2 also resets to the default clocks immediately, while others use a > fallthrough logic to commit the changes immediately.applied. > > This behavior needs to be kept as it is.
This behavior change is intentional, and these patch‑series introduces a unified transactional model for pp_od_clk_voltage: - `r` restores defaults within driver cache. - only `c` commits settings to PMFW. The existing immediate‑reset paths are ASIC‑specific inconsistencies. SMU 13.0.2 pushes default clock limits directly, whereas other backends achieve equivalent results via the commit path. This series unifies both under PowerPlay’s staged‑reset model. Btw, user space desiring immediate reset shall issue `"r"` followed by `"c"`. Best Regards, Kevin > > Thanks, > Lijo > > > > Thanks, > > Lijo > > > >> > > >> It also permits userspace to reset a staged configuration, adjust one > >> or more settings, and submit the final configuration with one commit, > without temporarily applying an intermediate default configuration. > >> > >> Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5690 > >> > >> Kevin Wang (7): > >> drm/amd/pm: stage od reset for smu 11.0.7 > >> drm/amd/pm: stage od reset for smu 13.0.2 > >> drm/amd/pm: stage od reset for smu 13.0.0/13.0.7 > >> drm/amd/pm: stage od reset for smu 13.0.6 > >> drm/amd/pm: stage od reset for smu 14.0.2 > >> drm/amd/pm: stage od reset for smu 15.0.8 > >> drm/amd/pm: stage od reset for smu vega20 > >> > >> .../drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c | 75 > ++++++++++++++-- > >> .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 2 +- > >> .../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 15 +--- > >> .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 2 +- > >> .../drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 85 > >> ++++++++++--------- > >> .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 2 +- > >> .../drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c | 2 +- > >> .../drm/amd/pm/swsmu/smu15/smu_v15_0_8_ppt.c | 50 ++++++----- > >> 8 files changed, 145 insertions(+), 88 deletions(-) > >> > >> -- > >> 2.55.0 > >> > >
