[PATCH 0/7] drm/amd/pm: stage OD reset until commit

[PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Kevin Wang]

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
                                                                                                                                                                                                                                                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

[PATCH 1/7] drm/amd/pm: stage od reset for smu 11.0.7

[Kevin Wang]

SMU 11.0.7 restores the boot OverDrive table for
PP_OD_RESTORE_DEFAULT_TABLE, then falls through to the upload path.
The reset therefore changes PMFW state before userspace writes c.

Leave the restored table staged in the driver cache.
PP_OD_COMMIT_DPM_TABLE remains responsible for submitting it to PMFW.

Signed-off-by: Kevin Wang <kevin.wang@amd.com>
---
 drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index a0f0e858e9de..e26c3e2dff23 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -2387,7 +2387,7 @@ static int sienna_cichlid_od_edit_dpm_table(struct smu_context *smu,
 		memcpy(table_context->overdrive_table,
 				table_context->boot_overdrive_table,
 				sizeof(OverDriveTable_t));
-		fallthrough;
+		break;
 
 	case PP_OD_COMMIT_DPM_TABLE:
 		if (memcmp(od_table, table_context->user_overdrive_table, sizeof(OverDriveTable_t))) {
-- 
2.55.0

[PATCH 2/7] drm/amd/pm: stage od reset for smu 13.0.2

[Kevin Wang]

SMU 13.0.2 restores the default GFXCLK range by sending a frequency
limit command and then clears the custom range. This bypasses the
staged pp_od_clk_voltage transaction.

Stage the default GFXCLK range in the custom state instead. The existing
PP_OD_COMMIT_DPM_TABLE path remains the sole PMFW update operation.

Signed-off-by: Kevin Wang <kevin.wang@amd.com>
---
 .../gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c    | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index 1aa589bdc301..d07ad50d2666 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -1354,17 +1354,10 @@ static int aldebaran_usr_edit_dpm_table(struct smu_context *smu, enum PP_OD_DPM_
 			dev_err(smu->adev->dev, "Input parameter number not correct\n");
 			return -EINVAL;
 		} else {
-			/* Use the default frequencies for manual and determinism mode */
-			min_clk = SMU_DPM_TABLE_MIN(
-				&dpm_context->dpm_tables.gfx_table);
-			max_clk = SMU_DPM_TABLE_MAX(
-				&dpm_context->dpm_tables.gfx_table);
-
-			ret = aldebaran_set_soft_freq_limited_range(
-				smu, SMU_GFXCLK, min_clk, max_clk, false);
-			if (ret)
-				return ret;
-			smu_v13_0_reset_custom_level(smu);
+			pstate_table->gfxclk_pstate.custom.min =
+				SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.gfx_table);
+			pstate_table->gfxclk_pstate.custom.max =
+				SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.gfx_table);
 		}
 		break;
 	case PP_OD_COMMIT_DPM_TABLE:
-- 
2.55.0

[PATCH 3/7] drm/amd/pm: stage od reset for smu 13.0.0/13.0.7

[Kevin Wang]

SMU 13.0.0 and SMU 13.0.7 copy the boot external OverDrive table on
reset, then upload it immediately. Keep the table in the driver cache
until the user writes c.

Signed-off-by: Kevin Wang <kevin.wang@amd.com>
---
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 2 +-
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
index 16a6b8fd832c..26668cb00e0a 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -1897,7 +1897,7 @@ static int smu_v13_0_0_od_edit_dpm_table(struct smu_context *smu,
 		       sizeof(OverDriveTableExternal_t));
 			od_table->OverDriveTable.FeatureCtrlMask = feature_ctrlmask;
 		}
-		fallthrough;
+		break;
 	case PP_OD_COMMIT_DPM_TABLE:
 		/*
 		 * The member below instructs PMFW the settings focused in
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index 5fe409a23772..b0399dd49639 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -1906,7 +1906,7 @@ static int smu_v13_0_7_od_edit_dpm_table(struct smu_context *smu,
 					sizeof(OverDriveTableExternal_t));
 			od_table->OverDriveTable.FeatureCtrlMask = feature_ctrlmask;
 		}
-		fallthrough;
+		break;
 
 	case PP_OD_COMMIT_DPM_TABLE:
 		/*
-- 
2.55.0

[PATCH 4/7] drm/amd/pm: stage od reset for smu 13.0.6

[Kevin Wang]

SMU 13.0.6 applies default GFXCLK, UCLK, and FCLK ranges directly from
PP_OD_RESTORE_DEFAULT_TABLE. This bypasses the staged OD transaction.

Stage defaults through one helper and let c submit them. Gate UCLK and
FCLK staging and commit on their DPM features, and require the UCLK
firmware capability before staging or submitting its limit.

Signed-off-by: Kevin Wang <kevin.wang@amd.com>
---
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c  | 85 ++++++++++---------
 1 file changed, 44 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
index 4dec3a93cb3d..169e38db629d 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
@@ -2130,14 +2130,45 @@ static int smu_v13_0_6_set_soft_freq_limited_range(struct smu_context *smu,
 	return ret;
 }
 
+static void smu_v13_0_6_stage_default_dpm_limits(struct smu_context *smu)
+{
+	struct smu_dpm_context *smu_dpm = &smu->smu_dpm;
+	struct smu_13_0_dpm_context *dpm_context = smu_dpm->dpm_context;
+	struct smu_umd_pstate_table *pstate_table = &smu->pstate_table;
+
+	pstate_table->gfxclk_pstate.custom.min =
+		SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.gfx_table);
+	pstate_table->gfxclk_pstate.custom.max =
+		SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.gfx_table);
+
+	if (smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT) &&
+	    smu_v13_0_6_cap_supported(smu, SMU_CAP(SET_UCLK_MAX))) {
+		pstate_table->uclk_pstate.custom.min =
+			SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.uclk_table);
+		pstate_table->uclk_pstate.custom.max =
+			SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.uclk_table);
+	} else {
+		pstate_table->uclk_pstate.custom.min = 0;
+		pstate_table->uclk_pstate.custom.max = 0;
+	}
+
+	if (smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_FCLK_BIT)) {
+		pstate_table->fclk_pstate.custom.min =
+			SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.fclk_table);
+		pstate_table->fclk_pstate.custom.max =
+			SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.fclk_table);
+	} else {
+		pstate_table->fclk_pstate.custom.min = 0;
+		pstate_table->fclk_pstate.custom.max = 0;
+	}
+}
+
 static int smu_v13_0_6_usr_edit_dpm_table(struct smu_context *smu,
 					  enum PP_OD_DPM_TABLE_COMMAND type,
 					  long input[], uint32_t size)
 {
 	struct smu_dpm_context *smu_dpm = &(smu->smu_dpm);
 	struct smu_13_0_dpm_context *dpm_context = smu_dpm->dpm_context;
-	struct smu_dpm_table *uclk_table = &dpm_context->dpm_tables.uclk_table;
-	struct smu_dpm_table *fclk_table = &dpm_context->dpm_tables.fclk_table;
 	struct smu_umd_pstate_table *pstate_table = &smu->pstate_table;
 	uint32_t min_clk;
 	uint32_t max_clk;
@@ -2258,42 +2289,8 @@ static int smu_v13_0_6_usr_edit_dpm_table(struct smu_context *smu,
 			dev_err(smu->adev->dev,
 				"Input parameter number not correct\n");
 			return -EINVAL;
-		} else {
-			/* Use the default frequencies for manual and determinism mode */
-			min_clk = SMU_DPM_TABLE_MIN(
-				&dpm_context->dpm_tables.gfx_table);
-			max_clk = SMU_DPM_TABLE_MAX(
-				&dpm_context->dpm_tables.gfx_table);
-
-			ret = smu_v13_0_6_set_soft_freq_limited_range(
-				smu, SMU_GFXCLK, min_clk, max_clk, false);
-
-			if (ret)
-				return ret;
-
-			if (SMU_DPM_TABLE_MAX(uclk_table) !=
-			    pstate_table->uclk_pstate.curr.max) {
-				min_clk = SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.uclk_table);
-				max_clk = SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.uclk_table);
-				ret = smu_v13_0_6_set_soft_freq_limited_range(smu,
-									      SMU_UCLK, min_clk,
-									      max_clk, false);
-				if (ret)
-					return ret;
-			}
-
-			if (SMU_DPM_TABLE_MAX(fclk_table) !=
-			    pstate_table->fclk_pstate.curr.max) {
-				max_clk = SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.fclk_table);
-				min_clk = SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.fclk_table);
-				ret = smu_v13_0_6_set_soft_freq_limited_range(smu,
-									      SMU_FCLK, min_clk,
-									      max_clk, false);
-				if (ret)
-					return ret;
-			}
-			smu_v13_0_reset_custom_level(smu);
 		}
+		smu_v13_0_6_stage_default_dpm_limits(smu);
 		break;
 	case PP_OD_COMMIT_DPM_TABLE:
 		if (size != 0) {
@@ -2318,8 +2315,10 @@ static int smu_v13_0_6_usr_edit_dpm_table(struct smu_context *smu,
 			if (ret)
 				return ret;
 
-			if (pstate_table->fclk_pstate.custom.max) {
-				min_clk = pstate_table->fclk_pstate.curr.min;
+			if (pstate_table->fclk_pstate.custom.max &&
+			    smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_FCLK_BIT)) {
+				min_clk = pstate_table->fclk_pstate.custom.min ?:
+					pstate_table->fclk_pstate.curr.min;
 				max_clk = pstate_table->fclk_pstate.custom.max;
 				ret = smu_v13_0_6_set_soft_freq_limited_range(smu,
 									      SMU_FCLK, min_clk,
@@ -2328,10 +2327,14 @@ static int smu_v13_0_6_usr_edit_dpm_table(struct smu_context *smu,
 					return ret;
 			}
 
-			if (!pstate_table->uclk_pstate.custom.max)
+			if (!pstate_table->uclk_pstate.custom.max ||
+			    !smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT) ||
+			    !smu_v13_0_6_cap_supported(smu,
+							     SMU_CAP(SET_UCLK_MAX)))
 				return 0;
 
-			min_clk = pstate_table->uclk_pstate.curr.min;
+			min_clk = pstate_table->uclk_pstate.custom.min ?:
+				pstate_table->uclk_pstate.curr.min;
 			max_clk = pstate_table->uclk_pstate.custom.max;
 			return smu_v13_0_6_set_soft_freq_limited_range(
 				smu, SMU_UCLK, min_clk, max_clk, false);
-- 
2.55.0

[PATCH 5/7] drm/amd/pm: stage od reset for smu 14.0.2

[Kevin Wang]

SMU 14.0.2 copies the boot external OverDrive table on reset and uploads
it immediately. Keep the table staged until c.

Signed-off-by: Kevin Wang <kevin.wang@amd.com>
---
 drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c
index 71c928e90264..8f297eaedfdf 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c
@@ -2762,7 +2762,7 @@ static int smu_v14_0_2_od_edit_dpm_table(struct smu_context *smu,
 		       sizeof(OverDriveTableExternal_t));
 			od_table->OverDriveTable.FeatureCtrlMask = feature_ctrlmask;
 		}
-		fallthrough;
+		break;
 	case PP_OD_COMMIT_DPM_TABLE:
 		/*
 		 * The member below instructs PMFW the settings focused in
-- 
2.55.0

[PATCH 6/7] drm/amd/pm: stage od reset for smu 15.0.8

[Kevin Wang]

SMU 15.0.8 applies default GFXCLK and UCLK ranges directly from reset.
Stage the defaults instead, leaving c as the only PMFW update operation.

Only stage and commit UCLK when its DPM feature is enabled. This matches
the edit path and avoids sending an unsupported UCLK limit command.

Signed-off-by: Kevin Wang <kevin.wang@amd.com>
---
 .../drm/amd/pm/swsmu/smu15/smu_v15_0_8_ppt.c  | 50 ++++++++++---------
 1 file changed, 27 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu15/smu_v15_0_8_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu15/smu_v15_0_8_ppt.c
index db0e0733588d..0f7a8b4585d2 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu15/smu_v15_0_8_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu15/smu_v15_0_8_ppt.c
@@ -2072,6 +2072,28 @@ static int smu_v15_0_8_set_soft_freq_limited_range(struct smu_context *smu,
 	return ret;
 }
 
+static void smu_v15_0_8_stage_default_dpm_limits(struct smu_context *smu)
+{
+	struct smu_dpm_context *smu_dpm = &smu->smu_dpm;
+	struct smu_15_0_dpm_context *dpm_context = smu_dpm->dpm_context;
+	struct smu_umd_pstate_table *pstate_table = &smu->pstate_table;
+
+	pstate_table->gfxclk_pstate.custom.min =
+		SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.gfx_table);
+	pstate_table->gfxclk_pstate.custom.max =
+		SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.gfx_table);
+
+	if (smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT)) {
+		pstate_table->uclk_pstate.custom.min =
+			SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.uclk_table);
+		pstate_table->uclk_pstate.custom.max =
+			SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.uclk_table);
+	} else {
+		pstate_table->uclk_pstate.custom.min = 0;
+		pstate_table->uclk_pstate.custom.max = 0;
+	}
+}
+
 static int smu_v15_0_8_od_edit_dpm_table(struct smu_context *smu,
 					 enum PP_OD_DPM_TABLE_COMMAND type,
 					 long input[], uint32_t size)
@@ -2159,27 +2181,7 @@ static int smu_v15_0_8_od_edit_dpm_table(struct smu_context *smu,
 			return -EINVAL;
 		}
 
-		/* Use the default frequencies for manual mode */
-		min_clk = SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.gfx_table);
-		max_clk = SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.gfx_table);
-
-		ret = smu_v15_0_8_set_soft_freq_limited_range(smu,
-							      SMU_GFXCLK,
-							      min_clk, max_clk,
-							      false);
-		if (ret)
-			return ret;
-
-		min_clk = SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.uclk_table);
-		max_clk = SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.uclk_table);
-		ret = smu_v15_0_8_set_soft_freq_limited_range(smu,
-							      SMU_UCLK,
-							      min_clk, max_clk,
-							      false);
-		if (ret)
-			return ret;
-
-		smu_cmn_reset_custom_level(smu);
+		smu_v15_0_8_stage_default_dpm_limits(smu);
 		break;
 	case PP_OD_COMMIT_DPM_TABLE:
 		if (size != 0) {
@@ -2207,8 +2209,10 @@ static int smu_v15_0_8_od_edit_dpm_table(struct smu_context *smu,
 			return ret;
 
 		/* Commit UCLK custom range (only max supported) */
-		if (pstate_table->uclk_pstate.custom.max) {
-			min_clk = pstate_table->uclk_pstate.curr.min;
+		if (pstate_table->uclk_pstate.custom.max &&
+		    smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT)) {
+			min_clk = pstate_table->uclk_pstate.custom.min ?:
+				pstate_table->uclk_pstate.curr.min;
 			max_clk = pstate_table->uclk_pstate.custom.max;
 			ret = smu_v15_0_8_set_soft_freq_limited_range(smu,
 								      SMU_UCLK,
-- 
2.55.0

[PATCH 7/7] drm/amd/pm: stage od reset for smu vega20

[Kevin Wang]

Vega20 handles PP_OD_RESTORE_DEFAULT_TABLE by reading the current
OverDrive table from the SMU. This discards uncommitted driver-side
edits, but does not restore the boot OD settings.

Rebuild the pp_od_clk_voltage-editable table fields from the OD8 defaults
saved during initialization. Leave the rebuilt table in the driver cache
until PP_OD_COMMIT_DPM_TABLE uploads it. Preserve a pending GFXCLK/UCLK
DPM-table refresh whenever reset stages different limits, so c keeps the
driver cache synchronized with PMFW.

Signed-off-by: Kevin Wang <kevin.wang@amd.com>
---
 .../drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c | 75 ++++++++++++++++---
 1 file changed, 66 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c
index e9c194056e32..aee9a26b1809 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c
@@ -2948,6 +2948,71 @@ static int vega20_set_watermarks_for_clocks_ranges(struct pp_hwmgr *hwmgr,
 	return 0;
 }
 
+static void vega20_od8_restore_default_settings(struct vega20_hwmgr *data)
+{
+	struct vega20_od8_single_setting *od8_settings =
+		data->od8_settings.od8_settings_array;
+	OverDriveTable_t *od_table = &data->smc_state_table.overdrive_table;
+
+	if (data->od8_settings.overdrive8_capabilities & OD8_GFXCLK_LIMITS) {
+		if (od_table->GfxclkFmin !=
+			    od8_settings[OD8_SETTING_GFXCLK_FMIN].default_value ||
+		    od_table->GfxclkFmax !=
+			    od8_settings[OD8_SETTING_GFXCLK_FMAX].default_value)
+			data->gfxclk_overdrive = true;
+
+		od_table->GfxclkFmin =
+			od8_settings[OD8_SETTING_GFXCLK_FMIN].default_value;
+		od_table->GfxclkFmax =
+			od8_settings[OD8_SETTING_GFXCLK_FMAX].default_value;
+		od8_settings[OD8_SETTING_GFXCLK_FMIN].current_value =
+			od8_settings[OD8_SETTING_GFXCLK_FMIN].default_value;
+		od8_settings[OD8_SETTING_GFXCLK_FMAX].current_value =
+			od8_settings[OD8_SETTING_GFXCLK_FMAX].default_value;
+	}
+
+	if (data->od8_settings.overdrive8_capabilities & OD8_GFXCLK_CURVE) {
+		od_table->GfxclkFreq1 =
+			od8_settings[OD8_SETTING_GFXCLK_FREQ1].default_value;
+		od_table->GfxclkVolt1 =
+			od8_settings[OD8_SETTING_GFXCLK_VOLTAGE1].default_value *
+			VOLTAGE_SCALE;
+		od_table->GfxclkFreq2 =
+			od8_settings[OD8_SETTING_GFXCLK_FREQ2].default_value;
+		od_table->GfxclkVolt2 =
+			od8_settings[OD8_SETTING_GFXCLK_VOLTAGE2].default_value *
+			VOLTAGE_SCALE;
+		od_table->GfxclkFreq3 =
+			od8_settings[OD8_SETTING_GFXCLK_FREQ3].default_value;
+		od_table->GfxclkVolt3 =
+			od8_settings[OD8_SETTING_GFXCLK_VOLTAGE3].default_value *
+			VOLTAGE_SCALE;
+		od8_settings[OD8_SETTING_GFXCLK_FREQ1].current_value =
+			od8_settings[OD8_SETTING_GFXCLK_FREQ1].default_value;
+		od8_settings[OD8_SETTING_GFXCLK_VOLTAGE1].current_value =
+			od8_settings[OD8_SETTING_GFXCLK_VOLTAGE1].default_value;
+		od8_settings[OD8_SETTING_GFXCLK_FREQ2].current_value =
+			od8_settings[OD8_SETTING_GFXCLK_FREQ2].default_value;
+		od8_settings[OD8_SETTING_GFXCLK_VOLTAGE2].current_value =
+			od8_settings[OD8_SETTING_GFXCLK_VOLTAGE2].default_value;
+		od8_settings[OD8_SETTING_GFXCLK_FREQ3].current_value =
+			od8_settings[OD8_SETTING_GFXCLK_FREQ3].default_value;
+		od8_settings[OD8_SETTING_GFXCLK_VOLTAGE3].current_value =
+			od8_settings[OD8_SETTING_GFXCLK_VOLTAGE3].default_value;
+	}
+
+	if (data->od8_settings.overdrive8_capabilities & OD8_UCLK_MAX) {
+		if (od_table->UclkFmax !=
+		    od8_settings[OD8_SETTING_UCLK_FMAX].default_value)
+			data->memclk_overdrive = true;
+
+		od_table->UclkFmax =
+			od8_settings[OD8_SETTING_UCLK_FMAX].default_value;
+		od8_settings[OD8_SETTING_UCLK_FMAX].current_value =
+			od8_settings[OD8_SETTING_UCLK_FMAX].default_value;
+	}
+}
+
 static int vega20_odn_edit_dpm_table(struct pp_hwmgr *hwmgr,
 					enum PP_OD_DPM_TABLE_COMMAND type,
 					long *input, uint32_t size)
@@ -3117,15 +3182,7 @@ static int vega20_odn_edit_dpm_table(struct pp_hwmgr *hwmgr,
 		break;
 
 	case PP_OD_RESTORE_DEFAULT_TABLE:
-		data->gfxclk_overdrive = false;
-		data->memclk_overdrive = false;
-
-		ret = smum_smc_table_manager(hwmgr,
-					     (uint8_t *)od_table,
-					     TABLE_OVERDRIVE, true);
-		PP_ASSERT_WITH_CODE(!ret,
-				"Failed to export overdrive table!",
-				return ret);
+		vega20_od8_restore_default_settings(data);
 		break;
 
 	case PP_OD_COMMIT_DPM_TABLE:
-- 
2.55.0

RE: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Feng, Kenneth]

AMD General

The uclk setting when uclk dpm is disabled looks redundant, other than that,
Series is Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>

-----Original Message-----
From: Wang, Kevin <Kevin.Wang@amd.com>
Sent: Monday, August 31, 2026 12:35 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking <Hawking.Zhang@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
Subject: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

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
                                                                                                                                                                                                                                                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

RE: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Wang, Kevin]

AMD General

> -----Original Message-----
> From: Feng, Kenneth <Kenneth.Feng@amd.com>
> Sent: Monday, August 31, 2026 4:10 PM
> To: Wang, Kevin <Kevin.Wang@amd.com>; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking
> <Hawking.Zhang@amd.com>
> Subject: RE: [PATCH 0/7] drm/amd/pm: stage OD reset until commit
>
> AMD General
>
> The uclk setting when uclk dpm is disabled looks redundant, other than that,

This is not redundant code. Before the user sends the 'c' <commit> command to the driver, the user may override other fields based on these default setting values.

Best Regards,
Kevin

> Series is Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
>
> -----Original Message-----
> From: Wang, Kevin <Kevin.Wang@amd.com>
> Sent: Monday, August 31, 2026 12:35 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking
> <Hawking.Zhang@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
> Subject: [PATCH 0/7] drm/amd/pm: stage OD reset until commit
>
> 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
>
> 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
>

Re: [PATCH 4/7] drm/amd/pm: stage od reset for smu 13.0.6

[Lazar, Lijo]

On 31-Aug-26 10:05 AM, Kevin Wang wrote:
> [Some people who received this message don't often get email from kevin.wang@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> SMU 13.0.6 applies default GFXCLK, UCLK, and FCLK ranges directly from
> PP_OD_RESTORE_DEFAULT_TABLE. This bypasses the staged OD transaction.
> 
> Stage defaults through one helper and let c submit them. Gate UCLK and
> FCLK staging and commit on their DPM features, and require the UCLK
> firmware capability before staging or submitting its limit.
> 
> Signed-off-by: Kevin Wang <kevin.wang@amd.com>
> ---
>   .../drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c  | 85 ++++++++++---------
>   1 file changed, 44 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> index 4dec3a93cb3d..169e38db629d 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> @@ -2130,14 +2130,45 @@ static int smu_v13_0_6_set_soft_freq_limited_range(struct smu_context *smu,
>          return ret;
>   }
> 
> +static void smu_v13_0_6_stage_default_dpm_limits(struct smu_context *smu)
> +{
> +       struct smu_dpm_context *smu_dpm = &smu->smu_dpm;
> +       struct smu_13_0_dpm_context *dpm_context = smu_dpm->dpm_context;
> +       struct smu_umd_pstate_table *pstate_table = &smu->pstate_table;
> +
> +       pstate_table->gfxclk_pstate.custom.min =
> +               SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.gfx_table);
> +       pstate_table->gfxclk_pstate.custom.max =
> +               SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.gfx_table);
> +
> +       if (smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT) &&
> +           smu_v13_0_6_cap_supported(smu, SMU_CAP(SET_UCLK_MAX))) {
> +               pstate_table->uclk_pstate.custom.min =
> +                       SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.uclk_table);
> +               pstate_table->uclk_pstate.custom.max =
> +                       SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.uclk_table);
> +       } else {
> +               pstate_table->uclk_pstate.custom.min = 0;
> +               pstate_table->uclk_pstate.custom.max = 0;
> +       }
> +
> +       if (smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_FCLK_BIT)) {
> +               pstate_table->fclk_pstate.custom.min =
> +                       SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.fclk_table);
> +               pstate_table->fclk_pstate.custom.max =
> +                       SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.fclk_table);
> +       } else {
> +               pstate_table->fclk_pstate.custom.min = 0;
> +               pstate_table->fclk_pstate.custom.max = 0;
> +       }
> +}

The default values shouldn't be put as custom min/max limits. The custom 
limits will keep non-zero values to indicate any custom limit is set or 
not. It's not used to keep the default limits.
> +
>   static int smu_v13_0_6_usr_edit_dpm_table(struct smu_context *smu,
>                                            enum PP_OD_DPM_TABLE_COMMAND type,
>                                            long input[], uint32_t size)
>   {
>          struct smu_dpm_context *smu_dpm = &(smu->smu_dpm);
>          struct smu_13_0_dpm_context *dpm_context = smu_dpm->dpm_context;
> -       struct smu_dpm_table *uclk_table = &dpm_context->dpm_tables.uclk_table;
> -       struct smu_dpm_table *fclk_table = &dpm_context->dpm_tables.fclk_table;
>          struct smu_umd_pstate_table *pstate_table = &smu->pstate_table;
>          uint32_t min_clk;
>          uint32_t max_clk;
> @@ -2258,42 +2289,8 @@ static int smu_v13_0_6_usr_edit_dpm_table(struct smu_context *smu,
>                          dev_err(smu->adev->dev,
>                                  "Input parameter number not correct\n");
>                          return -EINVAL;
> -               } else {
> -                       /* Use the default frequencies for manual and determinism mode */
> -                       min_clk = SMU_DPM_TABLE_MIN(
> -                               &dpm_context->dpm_tables.gfx_table);
> -                       max_clk = SMU_DPM_TABLE_MAX(
> -                               &dpm_context->dpm_tables.gfx_table);
> -
> -                       ret = smu_v13_0_6_set_soft_freq_limited_range(
> -                               smu, SMU_GFXCLK, min_clk, max_clk, false);
> -
> -                       if (ret)
> -                               return ret;
> -
> -                       if (SMU_DPM_TABLE_MAX(uclk_table) !=
> -                           pstate_table->uclk_pstate.curr.max) {
> -                               min_clk = SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.uclk_table);
> -                               max_clk = SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.uclk_table);
> -                               ret = smu_v13_0_6_set_soft_freq_limited_range(smu,
> -                                                                             SMU_UCLK, min_clk,
> -                                                                             max_clk, false);
> -                               if (ret)
> -                                       return ret;
> -                       }
> -
> -                       if (SMU_DPM_TABLE_MAX(fclk_table) !=
> -                           pstate_table->fclk_pstate.curr.max) {
> -                               max_clk = SMU_DPM_TABLE_MAX(&dpm_context->dpm_tables.fclk_table);
> -                               min_clk = SMU_DPM_TABLE_MIN(&dpm_context->dpm_tables.fclk_table);
> -                               ret = smu_v13_0_6_set_soft_freq_limited_range(smu,
> -                                                                             SMU_FCLK, min_clk,
> -                                                                             max_clk, false);
> -                               if (ret)
> -                                       return ret;
> -                       }
> -                       smu_v13_0_reset_custom_level(smu);
>                  }
> +               smu_v13_0_6_stage_default_dpm_limits(smu);
>                  break;
>          case PP_OD_COMMIT_DPM_TABLE:
>                  if (size != 0) {
> @@ -2318,8 +2315,10 @@ static int smu_v13_0_6_usr_edit_dpm_table(struct smu_context *smu,
>                          if (ret)
>                                  return ret;
> 
> -                       if (pstate_table->fclk_pstate.custom.max) {
> -                               min_clk = pstate_table->fclk_pstate.curr.min;
> +                       if (pstate_table->fclk_pstate.custom.max &&
> +                           smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_FCLK_BIT)) {
> +                               min_clk = pstate_table->fclk_pstate.custom.min ?:
> +                                       pstate_table->fclk_pstate.curr.min;

This is intentional to always enforce the min limit, there is no custom 
min limit allowed for FCLK.

>                                  max_clk = pstate_table->fclk_pstate.custom.max;
>                                  ret = smu_v13_0_6_set_soft_freq_limited_range(smu,
>                                                                                SMU_FCLK, min_clk,
> @@ -2328,10 +2327,14 @@ static int smu_v13_0_6_usr_edit_dpm_table(struct smu_context *smu,
>                                          return ret;
>                          }
> 
> -                       if (!pstate_table->uclk_pstate.custom.max)
> +                       if (!pstate_table->uclk_pstate.custom.max ||
> +                           !smu_cmn_feature_is_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT) ||
> +                           !smu_v13_0_6_cap_supported(smu,
> +                                                            SMU_CAP(SET_UCLK_MAX)))
>                                  return 0;
> 
> -                       min_clk = pstate_table->uclk_pstate.curr.min;
> +                       min_clk = pstate_table->uclk_pstate.custom.min ?:

Same here, there is no custom min allowed for UCLK.

Thanks,
Lijo

> +                               pstate_table->uclk_pstate.curr.min;
>                          max_clk = pstate_table->uclk_pstate.custom.max;
>                          return smu_v13_0_6_set_soft_freq_limited_range(
>                                  smu, SMU_UCLK, min_clk, max_clk, false);
> --
> 2.55.0
> 

Re: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Lazar, Lijo]

On 31-Aug-26 10:05 AM, Kevin Wang wrote:
> [Some people who received this message don't often get email from kevin.wang@amd.com. 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.

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
> 

Re: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Lazar, Lijo]

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 
>> kevin.wang@amd.com. 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.

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
>>
> 

RE: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Wang, Kevin]

AMD General

> -----Original Message-----
> From: Lazar, Lijo <Lijo.Lazar@amd.com>
> Sent: Monday, August 31, 2026 7:06 PM
> To: Wang, Kevin <Kevin.Wang@amd.com>; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking
> <Hawking.Zhang@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
> 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
> >> kevin.wang@amd.com. 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
> >>
> >

Re: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Lazar, Lijo]

On 31-Aug-26 5:36 PM, Wang, Kevin wrote:
> AMD General
> 
>> -----Original Message-----
>> From: Lazar, Lijo <Lijo.Lazar@amd.com>
>> Sent: Monday, August 31, 2026 7:06 PM
>> To: Wang, Kevin <Kevin.Wang@amd.com>; amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking
>> <Hawking.Zhang@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
>> 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
>>>> kevin.wang@amd.com. 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"`.
> 

This is what breaks existing userspace.

Only SMU 14.0.0/13.0.5/Navi10 are not resetting to default clocks with 
'r' operation. The documentation also gives the impression that 'r' 
doesn't require a commit.

"If you want to reset to the default power levels, write “r” (reset) to 
the file to reset them"

The patch should be to correct the non-conforming ones rather than 
enforcing a 'c' operation to reset.

Thanks,
Lijo
> 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
>>>>
>>>
> 

RE: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Wang, Kevin]

AMD General

> -----Original Message-----
> From: Lazar, Lijo <Lijo.Lazar@amd.com>
> Sent: Monday, August 31, 2026 8:22 PM
> To: Wang, Kevin <Kevin.Wang@amd.com>; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking
> <Hawking.Zhang@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
> Subject: Re: [PATCH 0/7] drm/amd/pm: stage OD reset until commit
>
>
>
> On 31-Aug-26 5:36 PM, Wang, Kevin wrote:
> > AMD General
> >
> >> -----Original Message-----
> >> From: Lazar, Lijo <Lijo.Lazar@amd.com>
> >> Sent: Monday, August 31, 2026 7:06 PM
> >> To: Wang, Kevin <Kevin.Wang@amd.com>; amd-gfx@lists.freedesktop.org
> >> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking
> >> <Hawking.Zhang@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
> >> 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
> >>>> kevin.wang@amd.com. 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"`.
> >
>
> This is what breaks existing userspace.

As stated earlier, this series fixes inconsistent driver behavior. Note that divergent semantics already exist across ASICs today;
without this fix, merely a different subset of ASICs would be affected. The series brings them under a unified transactional model.

Hi @Deucher, Alexander @Feng, Kenneth,
For driver‑behavior‑change concerns: I’m unsure which fix direction is better. Still, converging all hardware updates into the 'c' commit aids driver state maintenance.

Best Regards,
Kevin

>
> Only SMU 14.0.0/13.0.5/Navi10 are not resetting to default clocks with 'r'
> operation. The documentation also gives the impression that 'r'
> doesn't require a commit.
>
> "If you want to reset to the default power levels, write “r” (reset) to the file to
> reset them"
>
> The patch should be to correct the non-conforming ones rather than
> enforcing a 'c' operation to reset.
>
> Thanks,
> Lijo
> > 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
> >>>>
> >>>
> >

RE: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

[Feng, Kenneth]

AMD General

I just think either way is ok. It is a user convention definition.
Thanks.


-----Original Message-----
From: Wang, Kevin <Kevin.Wang@amd.com>
Sent: Monday, August 31, 2026 8:48 PM
To: Lazar, Lijo <Lijo.Lazar@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
Cc: Zhang, Hawking <Hawking.Zhang@amd.com>
Subject: RE: [PATCH 0/7] drm/amd/pm: stage OD reset until commit

AMD General

> -----Original Message-----
> From: Lazar, Lijo <Lijo.Lazar@amd.com>
> Sent: Monday, August 31, 2026 8:22 PM
> To: Wang, Kevin <Kevin.Wang@amd.com>; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking
> <Hawking.Zhang@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
> Subject: Re: [PATCH 0/7] drm/amd/pm: stage OD reset until commit
>
>
>
> On 31-Aug-26 5:36 PM, Wang, Kevin wrote:
> > AMD General
> >
> >> -----Original Message-----
> >> From: Lazar, Lijo <Lijo.Lazar@amd.com>
> >> Sent: Monday, August 31, 2026 7:06 PM
> >> To: Wang, Kevin <Kevin.Wang@amd.com>; amd-gfx@lists.freedesktop.org
> >> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Zhang, Hawking
> >> <Hawking.Zhang@amd.com>; Feng, Kenneth <Kenneth.Feng@amd.com>
> >> 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
> >>>> kevin.wang@amd.com. 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"`.
> >
>
> This is what breaks existing userspace.

As stated earlier, this series fixes inconsistent driver behavior. Note that divergent semantics already exist across ASICs today; without this fix, merely a different subset of ASICs would be affected. The series brings them under a unified transactional model.

Hi @Deucher, Alexander @Feng, Kenneth,
For driver‑behavior‑change concerns: I’m unsure which fix direction is better. Still, converging all hardware updates into the 'c' commit aids driver state maintenance.

Best Regards,
Kevin

>
> Only SMU 14.0.0/13.0.5/Navi10 are not resetting to default clocks with 'r'
> operation. The documentation also gives the impression that 'r'
> doesn't require a commit.
>
> "If you want to reset to the default power levels, write “r” (reset)
> to the file to reset them"
>
> The patch should be to correct the non-conforming ones rather than
> enforcing a 'c' operation to reset.
>
> Thanks,
> Lijo
> > 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
> >>>>
> >>>
> >