[PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[Timur Kristóf]

Fix various issues with the clocks stuck on SI
laptop dGPUs:

* vblank mistake when there are no displays connected
* forgot to notify SMU about DC->AC switch
* inconsistent values in VBIOS

While we are at it, also implement the DC->AC notification
for SMU7 as well, which is supposed to work the same way.

Jeremy Klarenbeek (2):
  drm/amd/pm/si: Fix updating clock limits from power states
  drm/amd/pm/si: Notify the SMC when switching to AC

Timur Kristóf (3):
  drm/amd/pm/si: Disregard vblank time when no displays are connected
  drm/amd/pm: Rename enable_bapm() to notify_ac_dc()
  drm/amd/pm/smu7: Notify SMU7 of DC->AC switch

 .../gpu/drm/amd/include/kgd_pp_interface.h    |  2 +-
 drivers/gpu/drm/amd/pm/amdgpu_dpm.c           |  8 +--
 drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c    |  6 +--
 drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c    | 50 ++++++++++++++-----
 .../gpu/drm/amd/pm/powerplay/amd_powerplay.c  | 12 +++++
 .../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c   | 15 ++++++
 drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h  |  1 +
 7 files changed, 74 insertions(+), 20 deletions(-)

-- 
2.54.0

[PATCH 1/5] drm/amd/pm/si: Disregard vblank time when no displays are connected

[Timur Kristóf]

When no displays are connected, there is no vblank
happening so the power management code shouldn't
worry about it.

This fixes a regression that caused the memory clock
to be stuck at maximum when there were no displays
connected to a SI GPU.

Fixes: 9003a0746864 ("drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3)")
Fixes: 9d73b107a61b ("drm/amd/pm: Use pm_display_cfg in legacy DPM (v2)")
Tested-by: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
---
 drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
index b75a6031c68a..5afe42918497 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
@@ -3076,6 +3076,10 @@ static bool si_dpm_vblank_too_short(void *handle)
 	/* we never hit the non-gddr5 limit so disable it */
 	u32 switch_limit = adev->gmc.vram_type == AMDGPU_VRAM_TYPE_GDDR5 ? 450 : 0;
 
+	/* Disregard vblank time when there are no displays connected */
+	if (!adev->pm.pm_display_cfg.num_display)
+		return false;
+
 	/* Consider zero vblank time too short and disable MCLK switching.
 	 * Note that the vblank time is set to maximum when no displays are attached,
 	 * so we'll still enable MCLK switching in that case.
-- 
2.54.0

Re: [PATCH 1/5] drm/amd/pm/si: Disregard vblank time when no displays are connected

[Alex Deucher]

On Tue, May 19, 2026 at 4:42 AM Timur Kristóf <timur.kristof@gmail.com> wrote:
>
> When no displays are connected, there is no vblank
> happening so the power management code shouldn't
> worry about it.
>
> This fixes a regression that caused the memory clock
> to be stuck at maximum when there were no displays
> connected to a SI GPU.
>
> Fixes: 9003a0746864 ("drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3)")
> Fixes: 9d73b107a61b ("drm/amd/pm: Use pm_display_cfg in legacy DPM (v2)")
> Tested-by: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com>
> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>

Series is:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
And applied.

Thanks!

> ---
>  drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
> index b75a6031c68a..5afe42918497 100644
> --- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
> @@ -3076,6 +3076,10 @@ static bool si_dpm_vblank_too_short(void *handle)
>         /* we never hit the non-gddr5 limit so disable it */
>         u32 switch_limit = adev->gmc.vram_type == AMDGPU_VRAM_TYPE_GDDR5 ? 450 : 0;
>
> +       /* Disregard vblank time when there are no displays connected */
> +       if (!adev->pm.pm_display_cfg.num_display)
> +               return false;
> +
>         /* Consider zero vblank time too short and disable MCLK switching.
>          * Note that the vblank time is set to maximum when no displays are attached,
>          * so we'll still enable MCLK switching in that case.
> --
> 2.54.0
>

[PATCH 2/5] drm/amd/pm: Rename enable_bapm() to notify_ac_dc()

[Timur Kristóf]

No functional changes, just change the name of this
function pointer to be more generic.

BAPM refers to a specific feature on KV, but other kinds of
ASICs may also need the SMU to be notified on AC/DC changes.

Also remove the argument and use adev->pm.ac_power instead.

Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
---
 drivers/gpu/drm/amd/include/kgd_pp_interface.h | 2 +-
 drivers/gpu/drm/amd/pm/amdgpu_dpm.c            | 8 ++++----
 drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c     | 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
index 1bbf531de5ed..27e0874d3ade 100644
--- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
@@ -417,7 +417,7 @@ struct amd_pm_funcs {
 	void (*display_configuration_changed)(void *handle);
 	void (*print_power_state)(void *handle, void *ps);
 	bool (*vblank_too_short)(void *handle);
-	void (*enable_bapm)(void *handle, bool enable);
+	void (*notify_ac_dc)(void *handle);
 	int (*check_state_equal)(void *handle,
 				void  *cps,
 				void  *rps,
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
index feadf604b474..f76ba6753551 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
@@ -33,8 +33,8 @@
 #include <linux/power_supply.h>
 #include "amdgpu_smu.h"
 
-#define amdgpu_dpm_enable_bapm(adev, e) \
-		((adev)->powerplay.pp_funcs->enable_bapm((adev)->powerplay.pp_handle, (e)))
+#define amdgpu_dpm_notify_ac_dc(adev) \
+		((adev)->powerplay.pp_funcs->notify_ac_dc((adev)->powerplay.pp_handle))
 
 #define amdgpu_dpm_is_legacy_dpm(adev) ((adev)->powerplay.pp_handle == (adev))
 
@@ -504,8 +504,8 @@ void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev)
 			adev->pm.ac_power = false;
 
 		if (adev->powerplay.pp_funcs &&
-		    adev->powerplay.pp_funcs->enable_bapm)
-			amdgpu_dpm_enable_bapm(adev, adev->pm.ac_power);
+		    adev->powerplay.pp_funcs->notify_ac_dc)
+			amdgpu_dpm_notify_ac_dc(adev);
 
 		if (is_support_sw_smu(adev))
 			smu_set_ac_dc(adev->powerplay.pp_handle);
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c b/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
index 33eb85dd68e9..49b95752de25 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
@@ -1233,14 +1233,14 @@ static void kv_update_requested_ps(struct amdgpu_device *adev,
 	adev->pm.dpm.requested_ps = &pi->requested_rps;
 }
 
-static void kv_dpm_enable_bapm(void *handle, bool enable)
+static void kv_dpm_enable_bapm(void *handle)
 {
 	struct amdgpu_device *adev = (struct amdgpu_device *)handle;
 	struct kv_power_info *pi = kv_get_pi(adev);
 	int ret;
 
 	if (pi->bapm_enable) {
-		ret = amdgpu_kv_smc_bapm_enable(adev, enable);
+		ret = amdgpu_kv_smc_bapm_enable(adev, adev->pm.ac_power);
 		if (ret)
 			drm_err(adev_to_drm(adev), "amdgpu_kv_smc_bapm_enable failed\n");
 	}
@@ -3342,7 +3342,7 @@ static const struct amd_pm_funcs kv_dpm_funcs = {
 	.debugfs_print_current_performance_level = &kv_dpm_debugfs_print_current_performance_level,
 	.force_performance_level = &kv_dpm_force_performance_level,
 	.set_powergating_by_smu = kv_set_powergating_by_smu,
-	.enable_bapm = &kv_dpm_enable_bapm,
+	.notify_ac_dc = &kv_dpm_enable_bapm,
 	.get_vce_clock_state = amdgpu_get_vce_clock_state,
 	.check_state_equal = kv_check_state_equal,
 	.read_sensor = &kv_dpm_read_sensor,
-- 
2.54.0

[PATCH 3/5] drm/amd/pm/smu7: Notify SMU7 of DC->AC switch

[Timur Kristóf]

When ATOM_PP_PLATFORM_CAP_HARDWAREDC is set,
the SMU has a GPIO pin for detecting AC/DC switch
and everything works automatically.

Otherwise when there is no GPIO pin, the SMU can
automatically detect switching to DC, but needs
to be notified of switching to AC.

Use PPSMC_MSG_RunningOnAC to notify the SMC
when switching to AC.

Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
---
 drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c  | 12 ++++++++++++
 .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c   | 15 +++++++++++++++
 drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h      |  1 +
 3 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
index 0bbb89788335..19e74baa2b85 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
@@ -1550,6 +1550,17 @@ static void pp_pm_compute_clocks(void *handle)
 			      NULL);
 }
 
+static void pp_dpm_notify_ac_dc(void *handle)
+{
+	struct pp_hwmgr *hwmgr = handle;
+
+	if (!hwmgr || !hwmgr->pm_en)
+		return;
+
+	if (hwmgr->hwmgr_func->notify_ac_dc)
+		hwmgr->hwmgr_func->notify_ac_dc(hwmgr);
+}
+
 static const struct amd_pm_funcs pp_dpm_funcs = {
 	.load_firmware = pp_dpm_load_fw,
 	.wait_for_fw_loading_complete = pp_dpm_fw_loading_complete,
@@ -1615,4 +1626,5 @@ static const struct amd_pm_funcs pp_dpm_funcs = {
 	.gfx_state_change_set = pp_gfx_state_change_set,
 	.get_smu_prv_buf_details = pp_get_prv_buffer_details,
 	.pm_compute_clocks = pp_pm_compute_clocks,
+	.notify_ac_dc = pp_dpm_notify_ac_dc,
 };
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
index 4436ab2bb51f..416b9380a70e 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
@@ -5854,6 +5854,20 @@ static int smu7_power_off_asic(struct pp_hwmgr *hwmgr)
 	return result;
 }
 
+static void smu7_notify_ac_dc(struct pp_hwmgr *hwmgr)
+{
+	struct amdgpu_device *adev = (struct amdgpu_device *)(hwmgr->adev);
+
+	/* Check if the platform already manages the AC/DC switch via dedicated GPIO. */
+	if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
+			    PHM_PlatformCaps_AutomaticDCTransition))
+		return;
+
+	/* The SMU automatically notices DC, but needs to be notified when switching to AC. */
+	if (adev->pm.ac_power)
+		smum_send_msg_to_smc(hwmgr, PPSMC_MSG_RunningOnAC, NULL);
+}
+
 static const struct pp_hwmgr_func smu7_hwmgr_funcs = {
 	.backend_init = &smu7_hwmgr_backend_init,
 	.backend_fini = &smu7_hwmgr_backend_fini,
@@ -5916,6 +5930,7 @@ static const struct pp_hwmgr_func smu7_hwmgr_funcs = {
 	.get_asic_baco_state = smu7_baco_get_state,
 	.set_asic_baco_state = smu7_baco_set_state,
 	.power_off_asic = smu7_power_off_asic,
+	.notify_ac_dc = smu7_notify_ac_dc,
 };
 
 uint8_t smu7_get_sleep_divider_id_from_clock(uint32_t clock,
diff --git a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
index 3ae45eac0c5c..84de2ccad7a3 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
@@ -364,6 +364,7 @@ struct pp_hwmgr_func {
 					bool disable);
 	ssize_t (*get_gpu_metrics)(struct pp_hwmgr *hwmgr, void **table);
 	int (*gfx_state_change)(struct pp_hwmgr *hwmgr, uint32_t state);
+	void (*notify_ac_dc)(struct pp_hwmgr *hwmgr);
 };
 
 struct pp_table_func {
-- 
2.54.0

[PATCH 4/5] drm/amd/pm/si: Fix updating clock limits from power states

[Timur Kristóf]

From: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com>

VBIOS can contain conflicting values between:
- the maximum allowed clocks and voltages on AC or DC
- the clocks and voltages in power states on AC or DC

Update maximum clock (and voltage) limits for both AC/DC
and take the highest value from the VBIOS limits and
the performance/battery power states. Previously this
was only done for AC, but is also needed for DC.

This commit fixes the behaviour on some laptop GPUs,
where the VBIOS limit was set to the lowest possible
clock frequency, so the GPU was stuck on the lowest
possible power level on battery.

Some affected GPUs are:
FirePro W4170M (Dell Precision M2800)
Radeon HD 8790M (Dell Latitude E6540)
and possibly other laptop GPUs.

Co-developed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com>
---
 drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 29 ++++++++++++++++++----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
index 5afe42918497..04f3ba5f8f46 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
@@ -7240,6 +7240,7 @@ static void si_parse_pplib_clock_info(struct amdgpu_device *adev,
 	struct evergreen_power_info *eg_pi = evergreen_get_pi(adev);
 	struct si_power_info *si_pi = si_get_pi(adev);
 	struct  si_ps *ps = si_get_ps(rps);
+	struct amdgpu_clock_and_voltage_limits *limits;
 	u16 leakage_voltage;
 	struct rv7xx_pl *pl = &ps->performance_levels[index];
 	int ret;
@@ -7299,12 +7300,30 @@ static void si_parse_pplib_clock_info(struct amdgpu_device *adev,
 		si_pi->mvdd_bootup_value = mvdd;
 	}
 
+	/*
+	 * Update maximum allowed clock limits.
+	 * VBIOS can contain conflicting values between:
+	 * - the maximum allowed clocks and voltages on AC or DC
+	 * - the clocks and voltages in power states on AC or DC
+	 */
 	if ((rps->class & ATOM_PPLIB_CLASSIFICATION_UI_MASK) ==
-	    ATOM_PPLIB_CLASSIFICATION_UI_PERFORMANCE) {
-		adev->pm.dpm.dyn_state.max_clock_voltage_on_ac.sclk = pl->sclk;
-		adev->pm.dpm.dyn_state.max_clock_voltage_on_ac.mclk = pl->mclk;
-		adev->pm.dpm.dyn_state.max_clock_voltage_on_ac.vddc = pl->vddc;
-		adev->pm.dpm.dyn_state.max_clock_voltage_on_ac.vddci = pl->vddci;
+	    ATOM_PPLIB_CLASSIFICATION_UI_PERFORMANCE)
+		limits = &adev->pm.dpm.dyn_state.max_clock_voltage_on_ac;
+	else if ((rps->class & ATOM_PPLIB_CLASSIFICATION_UI_MASK) ==
+		 ATOM_PPLIB_CLASSIFICATION_UI_BATTERY)
+		limits = &adev->pm.dpm.dyn_state.max_clock_voltage_on_dc;
+	else
+		limits = NULL;
+
+	if (limits) {
+		if (pl->sclk > limits->sclk)
+			limits->sclk = pl->sclk;
+		if (pl->mclk > limits->mclk)
+			limits->mclk = pl->mclk;
+		if (pl->vddc > limits->vddc)
+			limits->vddc = pl->vddc;
+		if (pl->vddci > limits->vddci)
+			limits->vddci = pl->vddci;
 	}
 }
 
-- 
2.54.0

[PATCH 5/5] drm/amd/pm/si: Notify the SMC when switching to AC

[Timur Kristóf]

From: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com>

There are some platforms that don't have a dedicated
GPIO line to manage the AC/DC switch. In this case,
the SI SMC automatically notices when switching to DC,
but needs to be notified when switching to AC.

Fixup and use si_notify_hw_of_powersource() which was
previously hidden behind an "#if 0".

This fixes some SI laptop GPUs to be able to use their
performance power states after switching from DC to AC.

Some affected GPUs are:
FirePro W4170M - Dell Precision M2800
Radeon HD 8790M - Dell Latitude E6540

Co-developed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com>
---
 drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
index 04f3ba5f8f46..832953941266 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
@@ -3888,16 +3888,18 @@ static void si_notify_hardware_vpu_recovery_event(struct amdgpu_device *adev)
 }
 #endif
 
-#if 0
-static int si_notify_hw_of_powersource(struct amdgpu_device *adev, bool ac_power)
+static void si_notify_hw_of_powersource(void *handle)
 {
-	if (ac_power)
-		return (amdgpu_si_send_msg_to_smc(adev, PPSMC_MSG_RunningOnAC) == PPSMC_Result_OK) ?
-			0 : -EINVAL;
+	struct amdgpu_device *adev = (struct amdgpu_device *)handle;
 
-	return 0;
+	/* Check if the platform already manages the AC/DC switch via dedicated GPIO. */
+	if (adev->pm.dpm.platform_caps & ATOM_PP_PLATFORM_CAP_HARDWAREDC)
+		return;
+
+	/* The SMU automatically notices DC, but needs to be notified when switching to AC. */
+	if (adev->pm.ac_power)
+		amdgpu_si_send_msg_to_smc(adev, PPSMC_MSG_RunningOnAC);
 }
-#endif
 
 static PPSMC_Result si_send_msg_to_smc_with_parameter(struct amdgpu_device *adev,
 						      PPSMC_Msg msg, u32 parameter)
@@ -8166,6 +8168,7 @@ static const struct amd_pm_funcs si_dpm_funcs = {
 	.get_vce_clock_state = amdgpu_get_vce_clock_state,
 	.read_sensor = &si_dpm_read_sensor,
 	.pm_compute_clocks = amdgpu_legacy_dpm_compute_clocks,
+	.notify_ac_dc = si_notify_hw_of_powersource,
 };
 
 static const struct amdgpu_irq_src_funcs si_dpm_irq_funcs = {
-- 
2.54.0

Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[Jeremy Klarenbeek]

[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]

Thanks for pulling this together, Timur and Alex. I just tried compiling
the series of 5 patches and it crashes my FirePro W4170M driver during boot:

[   41.095779] amdgpu 0000:01:00.0: [drm] *ERROR* UVD Firmware validate
fail (-22).
[   41.095788] amdgpu 0000:01:00.0: resume of IP block <uvd_v3_1> failed -22
[   41.095792] amdgpu 0000:01:00.0: amdgpu_device_ip_resume failed (-22).

I think it may be required after all to run the entire compute clocks
pipeline, or at least a bit more of it. I've been successfully running this
patch for the past few weeks:
https://github.com/luisfonsivevo/linux/commit/9b6090a4c145c988158d507c7b659c8765d9f7da
(I'm not allowed to create forks on the freedesktop GitLab)


On Tue, May 19, 2026 at 10:42 AM Timur Kristóf <timur.kristof@gmail.com>
wrote:

> Fix various issues with the clocks stuck on SI
> laptop dGPUs:
>
> * vblank mistake when there are no displays connected
> * forgot to notify SMU about DC->AC switch
> * inconsistent values in VBIOS
>
> While we are at it, also implement the DC->AC notification
> for SMU7 as well, which is supposed to work the same way.
>
> Jeremy Klarenbeek (2):
>   drm/amd/pm/si: Fix updating clock limits from power states
>   drm/amd/pm/si: Notify the SMC when switching to AC
>
> Timur Kristóf (3):
>   drm/amd/pm/si: Disregard vblank time when no displays are connected
>   drm/amd/pm: Rename enable_bapm() to notify_ac_dc()
>   drm/amd/pm/smu7: Notify SMU7 of DC->AC switch
>
>  .../gpu/drm/amd/include/kgd_pp_interface.h    |  2 +-
>  drivers/gpu/drm/amd/pm/amdgpu_dpm.c           |  8 +--
>  drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c    |  6 +--
>  drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c    | 50 ++++++++++++++-----
>  .../gpu/drm/amd/pm/powerplay/amd_powerplay.c  | 12 +++++
>  .../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c   | 15 ++++++
>  drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h  |  1 +
>  7 files changed, 74 insertions(+), 20 deletions(-)
>
> --
> 2.54.0
>
>

[-- Attachment #2: Type: text/html, Size: 2582 bytes --]

Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[Jeremy Klarenbeek]

[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]

Apologies for my late reply. I tested the patch series (SI laptop
1002:6606) and the problem remains where the clock speeds don't boost upon
switching to AC. Timur and I investigated this and found 2 problems:

1. It seems that it is necessary after all to recompute clock speeds when
toggling AC/DC. Sending PPSMC_MSG_RunningOnAC on its own has no effect.
Each ASIC family's apply_state_adjust_rules appears to be responsible for
the switch by setting the max_limits, and this function is only called as
part of computing clocks. I'm considering removing the .notify_ac_dc field
from the IP block entirely and just calling .pm_compute_clocks from
amdgpu_pm_acpi_event_handler, but I only know for certain that this works
for my GPU.
2. The ATOM_PP_PLATFORM_CAP_HARDWAREDC flag is enabled for my GPU, causing
PPSMC_MSG_RunningOnAC to never be sent. Either the flag is enabled
erroneously, or we're interpreting its intended usage incorrectly.

Unfortunately we're a bit stumped without either having documentation or a
stack of old laptops and could use some guidance on how to best proceed.
Thankfully the merged series doesn't seem to be causing any regressions at
least. I am currently running this workaround patch on top of the original
5:
https://github.com/luisfonsivevo/linux/commit/d74aa4e6fe4212c0a90467c45646bd138cea9a9d

On Tue, May 19, 2026 at 10:42 AM Timur Kristóf <timur.kristof@gmail.com>
wrote:

> Fix various issues with the clocks stuck on SI
> laptop dGPUs:
>
> * vblank mistake when there are no displays connected
> * forgot to notify SMU about DC->AC switch
> * inconsistent values in VBIOS
>
> While we are at it, also implement the DC->AC notification
> for SMU7 as well, which is supposed to work the same way.
>
> Jeremy Klarenbeek (2):
>   drm/amd/pm/si: Fix updating clock limits from power states
>   drm/amd/pm/si: Notify the SMC when switching to AC
>
> Timur Kristóf (3):
>   drm/amd/pm/si: Disregard vblank time when no displays are connected
>   drm/amd/pm: Rename enable_bapm() to notify_ac_dc()
>   drm/amd/pm/smu7: Notify SMU7 of DC->AC switch
>
>  .../gpu/drm/amd/include/kgd_pp_interface.h    |  2 +-
>  drivers/gpu/drm/amd/pm/amdgpu_dpm.c           |  8 +--
>  drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c    |  6 +--
>  drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c    | 50 ++++++++++++++-----
>  .../gpu/drm/amd/pm/powerplay/amd_powerplay.c  | 12 +++++
>  .../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c   | 15 ++++++
>  drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h  |  1 +
>  7 files changed, 74 insertions(+), 20 deletions(-)
>
> --
> 2.54.0
>
>

[-- Attachment #2: Type: text/html, Size: 3187 bytes --]

Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[Timur Kristóf]

Hi Jeremy & Alex,

> Apologies for my late reply. I tested the patch series (SI laptop
> 1002:6606) and the problem remains where the clock speeds don't boost upon
> switching to AC. Timur and I investigated this and found 2 problems

Thanks for getting back to us on this topic.
At Alex's suggestion, I removed the clock recalculation and added the check to 
verify ATOM_PP_PLATFORM_CAP_HARDWAREDC. I'm sad to hear that this broke your 
patches. I apologize for that.

Unfortunately I don't have a SI laptop GPU to test this stuff, so there was no 
way for me to verify the correctness of those changes before I sent the 
patches to the mailing list.

> 1. It seems that it is necessary after all to recompute clock speeds when
> toggling AC/DC. Sending PPSMC_MSG_RunningOnAC on its own has no effect.
> Each ASIC family's apply_state_adjust_rules appears to be responsible for
> the switch by setting the max_limits, and this function is only called as
> part of computing clocks.

That's right. I took another look at:
si_apply_state_adjust_rules()
smu7_apply_state_adjust_rules()

Both of these rely on adev->pm.ac_power when determining max_limits, and they 
set the maximum clocks accordingly. We should indeed re-calculate these clocks 
on both SI and SMU7 when there is an AC/DC switch to make sure to apply the 
updated max_limits. Additionally I think we should probably lock the mutexes 
to ensure that we are sending only one message at a time.

My suggestion would be to call pm_compute_clocks() inside notify_ac_dc(), and 
also to lock the mutexes:
https://gitlab.freedesktop.org/Venemo/linux/-/commit/
e98279dff480cc297cbb1fe50c2b71ebd65b9576

if that works, I'd like to submit that patch (and will also port it to SMU7).

> I'm considering removing the .notify_ac_dc field
> from the IP block entirely and just calling .pm_compute_clocks from
> amdgpu_pm_acpi_event_handler, but I only know for certain that this works
> for my GPU.

I don't agree with that. amdgpu_dpm is generic between all supported HW 
generations and shouldn't contain HW generation specific code. Also, it clearly 
doesn't work the same way on every GPU generation, so we shouldn't generalize.

Furthermore, we should minimize the amount of messages we send to the SMU, so 
we shouldn't send the RunningOnAC message every time we recompute the clocks, 
only when it actually switches to AC.

> 2. The ATOM_PP_PLATFORM_CAP_HARDWAREDC flag is enabled for my GPU, causing
> PPSMC_MSG_RunningOnAC to never be sent. Either the flag is enabled
> erroneously, or we're interpreting its intended usage incorrectly.

It's hard to judge that without having access to the hardware or docs.
Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on your 
laptop? Isn't it enough to just re-compute the clocks?

Can you check what exactly is the value of adev->pm.dpm.platform_caps on your 
laptop? Maybe we are looking at the wrong flag, or maybe the HARDWAREDC flag 
only refers to the AC->DC transition and not the DC->AC transition.

This is just guesswork on my part, but maybe we should look at the 
SBIOSPOWERSOURCE flag instead, which is explained in pptable_v1_0.h:
/* This cap indicates whether power source notificaiton is done by SBIOS 
directly. */
Can you check if this flag is set on your laptop?

Thanks & best regards,
Timur

Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[Deucher, Alexander]

[-- Attachment #1: Type: text/plain, Size: 3882 bytes --]

AMD General

I dug into this a bit more and the ATOM_PP_PLATFORM_CAP_HARDWAREDC check is inverted.  Switching that should fix it.

Alex

________________________________
From: Timur Kristóf <timur.kristof@gmail.com>
Sent: Sunday, May 24, 2026 7:32 AM
To: amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>; Deucher, Alexander <Alexander.Deucher@amd.com>; Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com>
Subject: Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

Hi Jeremy & Alex,

> Apologies for my late reply. I tested the patch series (SI laptop
> 1002:6606) and the problem remains where the clock speeds don't boost upon
> switching to AC. Timur and I investigated this and found 2 problems

Thanks for getting back to us on this topic.
At Alex's suggestion, I removed the clock recalculation and added the check to
verify ATOM_PP_PLATFORM_CAP_HARDWAREDC. I'm sad to hear that this broke your
patches. I apologize for that.

Unfortunately I don't have a SI laptop GPU to test this stuff, so there was no
way for me to verify the correctness of those changes before I sent the
patches to the mailing list.

> 1. It seems that it is necessary after all to recompute clock speeds when
> toggling AC/DC. Sending PPSMC_MSG_RunningOnAC on its own has no effect.
> Each ASIC family's apply_state_adjust_rules appears to be responsible for
> the switch by setting the max_limits, and this function is only called as
> part of computing clocks.

That's right. I took another look at:
si_apply_state_adjust_rules()
smu7_apply_state_adjust_rules()

Both of these rely on adev->pm.ac_power when determining max_limits, and they
set the maximum clocks accordingly. We should indeed re-calculate these clocks
on both SI and SMU7 when there is an AC/DC switch to make sure to apply the
updated max_limits. Additionally I think we should probably lock the mutexes
to ensure that we are sending only one message at a time.

My suggestion would be to call pm_compute_clocks() inside notify_ac_dc(), and
also to lock the mutexes:
https://gitlab.freedesktop.org/Venemo/linux/-/commit/
e98279dff480cc297cbb1fe50c2b71ebd65b9576

if that works, I'd like to submit that patch (and will also port it to SMU7).

> I'm considering removing the .notify_ac_dc field
> from the IP block entirely and just calling .pm_compute_clocks from
> amdgpu_pm_acpi_event_handler, but I only know for certain that this works
> for my GPU.

I don't agree with that. amdgpu_dpm is generic between all supported HW
generations and shouldn't contain HW generation specific code. Also, it clearly
doesn't work the same way on every GPU generation, so we shouldn't generalize.

Furthermore, we should minimize the amount of messages we send to the SMU, so
we shouldn't send the RunningOnAC message every time we recompute the clocks,
only when it actually switches to AC.

> 2. The ATOM_PP_PLATFORM_CAP_HARDWAREDC flag is enabled for my GPU, causing
> PPSMC_MSG_RunningOnAC to never be sent. Either the flag is enabled
> erroneously, or we're interpreting its intended usage incorrectly.

It's hard to judge that without having access to the hardware or docs.
Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on your
laptop? Isn't it enough to just re-compute the clocks?

Can you check what exactly is the value of adev->pm.dpm.platform_caps on your
laptop? Maybe we are looking at the wrong flag, or maybe the HARDWAREDC flag
only refers to the AC->DC transition and not the DC->AC transition.

This is just guesswork on my part, but maybe we should look at the
SBIOSPOWERSOURCE flag instead, which is explained in pptable_v1_0.h:
/* This cap indicates whether power source notificaiton is done by SBIOS
directly. */
Can you check if this flag is set on your laptop?

Thanks & best regards,
Timur




[-- Attachment #2: Type: text/html, Size: 5874 bytes --]

Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[Jeremy Klarenbeek]

[-- Attachment #1: Type: text/plain, Size: 5910 bytes --]

Thanks everyone.

> My suggestion would be to call pm_compute_clocks() inside notify_ac_dc()

I tried this patch and it's not working. The specific behavior I see:
1. Clocks do not respond to plugging/unplugging. Always idle.
2. Severe system stability issues. After opening a process that uses the
AMDGPU, opening any more GPU processes (glxgears, radeontop, etc.) hangs
forever during init. The system hangs while shutting down and requires
force power off.
3. This message is seen in dmesg. Not sure if it's related.
[  151.684427] amdgpu 0000:01:00.0: bo 00000000c5a63ba0 va
0x000010cb00-0x000010cb53 conflict with 0x000010cb44-0x000010cb45

> Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on your
laptop?
Yes, without sending this message, the SMC switches to idle speeds instead
of AC/performance speeds. Unplugging the laptop ironically makes it clock
back up instead of down. This fix was found while reverse engineering the
SMC and confirmed by the clock speeds beginning to rise after implementing
the message. Commenting out just the one line that sends the message undoes
the fix.

> the ATOM_PP_PLATFORM_CAP_HARDWAREDC check is inverted
I've implemented this into my branch. Thanks for checking.

Here is the current state, still a 6th commit on top of the original series
of 5: https://github.com/luisfonsivevo/linux/commit/083a2bbe81d6for
applyingfdc670b5890de661a3bdd42e9b80
<https://github.com/luisfonsivevo/linux/commit/083a2bbe81d6fdc670b5890de661a3bdd42e9b80>

This has been working reliably for a week without any problems and I'd be
happy to submit it if there are no objections. A separate commit will be
needed to apply this to SMU7.

On Fri, May 29, 2026 at 10:33 PM Deucher, Alexander <
Alexander.Deucher@amd.com> wrote:

> AMD General
>
> I dug into this a bit more and the ATOM_PP_PLATFORM_CAP_HARDWAREDC check
> is inverted.  Switching that should fix it.
>
> Alex
>
> ------------------------------
> *From:* Timur Kristóf <timur.kristof@gmail.com>
> *Sent:* Sunday, May 24, 2026 7:32 AM
> *To:* amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>;
> Deucher, Alexander <Alexander.Deucher@amd.com>; Jeremy Klarenbeek <
> jeremy.klarenbeek99@gmail.com>
> *Subject:* Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7
>
> Hi Jeremy & Alex,
>
> > Apologies for my late reply. I tested the patch series (SI laptop
> > 1002:6606) and the problem remains where the clock speeds don't boost
> upon
> > switching to AC. Timur and I investigated this and found 2 problems
>
> Thanks for getting back to us on this topic.
> At Alex's suggestion, I removed the clock recalculation and added the
> check to
> verify ATOM_PP_PLATFORM_CAP_HARDWAREDC. I'm sad to hear that this broke
> your
> patches. I apologize for that.
>
> Unfortunately I don't have a SI laptop GPU to test this stuff, so there
> was no
> way for me to verify the correctness of those changes before I sent the
> patches to the mailing list.
>
> > 1. It seems that it is necessary after all to recompute clock speeds when
> > toggling AC/DC. Sending PPSMC_MSG_RunningOnAC on its own has no effect.
> > Each ASIC family's apply_state_adjust_rules appears to be responsible for
> > the switch by setting the max_limits, and this function is only called as
> > part of computing clocks.
>
> That's right. I took another look at:
> si_apply_state_adjust_rules()
> smu7_apply_state_adjust_rules()
>
> Both of these rely on adev->pm.ac_power when determining max_limits, and
> they
> set the maximum clocks accordingly. We should indeed re-calculate these
> clocks
> on both SI and SMU7 when there is an AC/DC switch to make sure to apply
> the
> updated max_limits. Additionally I think we should probably lock the
> mutexes
> to ensure that we are sending only one message at a time.
>
> My suggestion would be to call pm_compute_clocks() inside notify_ac_dc(),
> and
> also to lock the mutexes:
> https://gitlab.freedesktop.org/Venemo/linux/-/commit/
> e98279dff480cc297cbb1fe50c2b71ebd65b9576
>
> if that works, I'd like to submit that patch (and will also port it to
> SMU7).
>
> > I'm considering removing the .notify_ac_dc field
> > from the IP block entirely and just calling .pm_compute_clocks from
> > amdgpu_pm_acpi_event_handler, but I only know for certain that this works
> > for my GPU.
>
> I don't agree with that. amdgpu_dpm is generic between all supported HW
> generations and shouldn't contain HW generation specific code. Also, it
> clearly
> doesn't work the same way on every GPU generation, so we shouldn't
> generalize.
>
> Furthermore, we should minimize the amount of messages we send to the SMU,
> so
> we shouldn't send the RunningOnAC message every time we recompute the
> clocks,
> only when it actually switches to AC.
>
> > 2. The ATOM_PP_PLATFORM_CAP_HARDWAREDC flag is enabled for my GPU,
> causing
> > PPSMC_MSG_RunningOnAC to never be sent. Either the flag is enabled
> > erroneously, or we're interpreting its intended usage incorrectly.
>
> It's hard to judge that without having access to the hardware or docs.
> Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on your
> laptop? Isn't it enough to just re-compute the clocks?
>
> Can you check what exactly is the value of adev->pm.dpm.platform_caps on
> your
> laptop? Maybe we are looking at the wrong flag, or maybe the HARDWAREDC
> flag
> only refers to the AC->DC transition and not the DC->AC transition.
>
> This is just guesswork on my part, but maybe we should look at the
> SBIOSPOWERSOURCE flag instead, which is explained in pptable_v1_0.h:
> /* This cap indicates whether power source notificaiton is done by SBIOS
> directly. */
> Can you check if this flag is set on your laptop?
>
> Thanks & best regards,
> Timur
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 8190 bytes --]

Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[Timur Kristóf]

On 2026. május 30., szombat 12:07:12 közép-európai nyári idő Jeremy Klarenbeek 
wrote:
> Thanks everyone.
> 
> > My suggestion would be to call pm_compute_clocks() inside notify_ac_dc()
> 
> I tried this patch and it's not working.

Of course not. It wouldn't work without also inverting the HARDWAREDC check.

> The specific behavior I see:
> 1. Clocks do not respond to plugging/unplugging. Always idle.
> 2. Severe system stability issues. After opening a process that uses the
> AMDGPU, opening any more GPU processes (glxgears, radeontop, etc.) hangs
> forever during init. The system hangs while shutting down and requires
> force power off.
> 3. This message is seen in dmesg. Not sure if it's related.
> [  151.684427] amdgpu 0000:01:00.0: bo 00000000c5a63ba0 va
> 0x000010cb00-0x000010cb53 conflict with 0x000010cb44-0x000010cb45
> 
> > Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on your
> 
> laptop?
> Yes, without sending this message, the SMC switches to idle speeds instead
> of AC/performance speeds. Unplugging the laptop ironically makes it clock
> back up instead of down. This fix was found while reverse engineering the
> SMC and confirmed by the clock speeds beginning to rise after implementing
> the message. Commenting out just the one line that sends the message undoes
> the fix.
> 
> > the ATOM_PP_PLATFORM_CAP_HARDWAREDC check is inverted
> 
> I've implemented this into my branch. Thanks for checking.
> 
> Here is the current state, still a 6th commit on top of the original series
> of 5: https://github.com/luisfonsivevo/linux/commit/083a2bbe81d6for
> applyingfdc670b5890de661a3bdd42e9b80
> <https://github.com/luisfonsivevo/linux/commit/083a2bbe81d6fdc670b5890de661a
> 3bdd42e9b80>
> 
> This has been working reliably for a week without any problems and I'd be
> happy to submit it if there are no objections. A separate commit will be
> needed to apply this to SMU7.
> 
> On Fri, May 29, 2026 at 10:33 PM Deucher, Alexander <
> 
> Alexander.Deucher@amd.com> wrote:
> > AMD General
> > 
> > I dug into this a bit more and the ATOM_PP_PLATFORM_CAP_HARDWAREDC check
> > is inverted.  Switching that should fix it.
> > 
> > Alex
> > 
> > ------------------------------
> > *From:* Timur Kristóf <timur.kristof@gmail.com>
> > *Sent:* Sunday, May 24, 2026 7:32 AM
> > *To:* amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>;
> > Deucher, Alexander <Alexander.Deucher@amd.com>; Jeremy Klarenbeek <
> > jeremy.klarenbeek99@gmail.com>
> > *Subject:* Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7
> > 
> > Hi Jeremy & Alex,
> > 
> > > Apologies for my late reply. I tested the patch series (SI laptop
> > > 1002:6606) and the problem remains where the clock speeds don't boost
> > 
> > upon
> > 
> > > switching to AC. Timur and I investigated this and found 2 problems
> > 
> > Thanks for getting back to us on this topic.
> > At Alex's suggestion, I removed the clock recalculation and added the
> > check to
> > verify ATOM_PP_PLATFORM_CAP_HARDWAREDC. I'm sad to hear that this broke
> > your
> > patches. I apologize for that.
> > 
> > Unfortunately I don't have a SI laptop GPU to test this stuff, so there
> > was no
> > way for me to verify the correctness of those changes before I sent the
> > patches to the mailing list.
> > 
> > > 1. It seems that it is necessary after all to recompute clock speeds
> > > when
> > > toggling AC/DC. Sending PPSMC_MSG_RunningOnAC on its own has no effect.
> > > Each ASIC family's apply_state_adjust_rules appears to be responsible
> > > for
> > > the switch by setting the max_limits, and this function is only called
> > > as
> > > part of computing clocks.
> > 
> > That's right. I took another look at:
> > si_apply_state_adjust_rules()
> > smu7_apply_state_adjust_rules()
> > 
> > Both of these rely on adev->pm.ac_power when determining max_limits, and
> > they
> > set the maximum clocks accordingly. We should indeed re-calculate these
> > clocks
> > on both SI and SMU7 when there is an AC/DC switch to make sure to apply
> > the
> > updated max_limits. Additionally I think we should probably lock the
> > mutexes
> > to ensure that we are sending only one message at a time.
> > 
> > My suggestion would be to call pm_compute_clocks() inside notify_ac_dc(),
> > and
> > also to lock the mutexes:
> > https://gitlab.freedesktop.org/Venemo/linux/-/commit/
> > e98279dff480cc297cbb1fe50c2b71ebd65b9576
> > 
> > if that works, I'd like to submit that patch (and will also port it to
> > SMU7).
> > 
> > > I'm considering removing the .notify_ac_dc field
> > > from the IP block entirely and just calling .pm_compute_clocks from
> > > amdgpu_pm_acpi_event_handler, but I only know for certain that this
> > > works
> > > for my GPU.
> > 
> > I don't agree with that. amdgpu_dpm is generic between all supported HW
> > generations and shouldn't contain HW generation specific code. Also, it
> > clearly
> > doesn't work the same way on every GPU generation, so we shouldn't
> > generalize.
> > 
> > Furthermore, we should minimize the amount of messages we send to the SMU,
> > so
> > we shouldn't send the RunningOnAC message every time we recompute the
> > clocks,
> > only when it actually switches to AC.
> > 
> > > 2. The ATOM_PP_PLATFORM_CAP_HARDWAREDC flag is enabled for my GPU,
> > 
> > causing
> > 
> > > PPSMC_MSG_RunningOnAC to never be sent. Either the flag is enabled
> > > erroneously, or we're interpreting its intended usage incorrectly.
> > 
> > It's hard to judge that without having access to the hardware or docs.
> > Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on your
> > laptop? Isn't it enough to just re-compute the clocks?
> > 
> > Can you check what exactly is the value of adev->pm.dpm.platform_caps on
> > your
> > laptop? Maybe we are looking at the wrong flag, or maybe the HARDWAREDC
> > flag
> > only refers to the AC->DC transition and not the DC->AC transition.
> > 
> > This is just guesswork on my part, but maybe we should look at the
> > SBIOSPOWERSOURCE flag instead, which is explained in pptable_v1_0.h:
> > /* This cap indicates whether power source notificaiton is done by SBIOS
> > directly. */
> > Can you check if this flag is set on your laptop?
> > 
> > Thanks & best regards,
> > Timur

Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7

[Jeremy Klarenbeek]

[-- Attachment #1: Type: text/plain, Size: 7166 bytes --]

I tested your patch without the ATOM_PP_PLATFORM_CAP_HARDWAREDC early exit
and saw the same behavior. Looks like it's a mutex issue:
both amdgpu_pm_acpi_event_handler and the modified
si_notify_hw_of_powersource are attempting to lock the power manager mutex
on the same thread.

On Sat, May 30, 2026 at 12:32 PM Timur Kristóf <timur.kristof@gmail.com>
wrote:

> On 2026. május 30., szombat 12:07:12 közép-európai nyári idő Jeremy
> Klarenbeek
> wrote:
> > Thanks everyone.
> >
> > > My suggestion would be to call pm_compute_clocks() inside
> notify_ac_dc()
> >
> > I tried this patch and it's not working.
>
> Of course not. It wouldn't work without also inverting the HARDWAREDC
> check.
>
> > The specific behavior I see:
> > 1. Clocks do not respond to plugging/unplugging. Always idle.
> > 2. Severe system stability issues. After opening a process that uses the
> > AMDGPU, opening any more GPU processes (glxgears, radeontop, etc.) hangs
> > forever during init. The system hangs while shutting down and requires
> > force power off.
> > 3. This message is seen in dmesg. Not sure if it's related.
> > [  151.684427] amdgpu 0000:01:00.0: bo 00000000c5a63ba0 va
> > 0x000010cb00-0x000010cb53 conflict with 0x000010cb44-0x000010cb45
> >
> > > Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on
> your
> >
> > laptop?
> > Yes, without sending this message, the SMC switches to idle speeds
> instead
> > of AC/performance speeds. Unplugging the laptop ironically makes it clock
> > back up instead of down. This fix was found while reverse engineering the
> > SMC and confirmed by the clock speeds beginning to rise after
> implementing
> > the message. Commenting out just the one line that sends the message
> undoes
> > the fix.
> >
> > > the ATOM_PP_PLATFORM_CAP_HARDWAREDC check is inverted
> >
> > I've implemented this into my branch. Thanks for checking.
> >
> > Here is the current state, still a 6th commit on top of the original
> series
> > of 5: https://github.com/luisfonsivevo/linux/commit/083a2bbe81d6for
> > applyingfdc670b5890de661a3bdd42e9b80
> > <
> https://github.com/luisfonsivevo/linux/commit/083a2bbe81d6fdc670b5890de661a
> > 3bdd42e9b80>
> >
> > This has been working reliably for a week without any problems and I'd be
> > happy to submit it if there are no objections. A separate commit will be
> > needed to apply this to SMU7.
> >
> > On Fri, May 29, 2026 at 10:33 PM Deucher, Alexander <
> >
> > Alexander.Deucher@amd.com> wrote:
> > > AMD General
> > >
> > > I dug into this a bit more and the ATOM_PP_PLATFORM_CAP_HARDWAREDC
> check
> > > is inverted.  Switching that should fix it.
> > >
> > > Alex
> > >
> > > ------------------------------
> > > *From:* Timur Kristóf <timur.kristof@gmail.com>
> > > *Sent:* Sunday, May 24, 2026 7:32 AM
> > > *To:* amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>;
> > > Deucher, Alexander <Alexander.Deucher@amd.com>; Jeremy Klarenbeek <
> > > jeremy.klarenbeek99@gmail.com>
> > > *Subject:* Re: [PATCH 0/5] drm/amd/pm: Fix laptop issues on SMU6-7
> > >
> > > Hi Jeremy & Alex,
> > >
> > > > Apologies for my late reply. I tested the patch series (SI laptop
> > > > 1002:6606) and the problem remains where the clock speeds don't boost
> > >
> > > upon
> > >
> > > > switching to AC. Timur and I investigated this and found 2 problems
> > >
> > > Thanks for getting back to us on this topic.
> > > At Alex's suggestion, I removed the clock recalculation and added the
> > > check to
> > > verify ATOM_PP_PLATFORM_CAP_HARDWAREDC. I'm sad to hear that this broke
> > > your
> > > patches. I apologize for that.
> > >
> > > Unfortunately I don't have a SI laptop GPU to test this stuff, so there
> > > was no
> > > way for me to verify the correctness of those changes before I sent the
> > > patches to the mailing list.
> > >
> > > > 1. It seems that it is necessary after all to recompute clock speeds
> > > > when
> > > > toggling AC/DC. Sending PPSMC_MSG_RunningOnAC on its own has no
> effect.
> > > > Each ASIC family's apply_state_adjust_rules appears to be responsible
> > > > for
> > > > the switch by setting the max_limits, and this function is only
> called
> > > > as
> > > > part of computing clocks.
> > >
> > > That's right. I took another look at:
> > > si_apply_state_adjust_rules()
> > > smu7_apply_state_adjust_rules()
> > >
> > > Both of these rely on adev->pm.ac_power when determining max_limits,
> and
> > > they
> > > set the maximum clocks accordingly. We should indeed re-calculate these
> > > clocks
> > > on both SI and SMU7 when there is an AC/DC switch to make sure to apply
> > > the
> > > updated max_limits. Additionally I think we should probably lock the
> > > mutexes
> > > to ensure that we are sending only one message at a time.
> > >
> > > My suggestion would be to call pm_compute_clocks() inside
> notify_ac_dc(),
> > > and
> > > also to lock the mutexes:
> > > https://gitlab.freedesktop.org/Venemo/linux/-/commit/
> > > e98279dff480cc297cbb1fe50c2b71ebd65b9576
> > >
> > > if that works, I'd like to submit that patch (and will also port it to
> > > SMU7).
> > >
> > > > I'm considering removing the .notify_ac_dc field
> > > > from the IP block entirely and just calling .pm_compute_clocks from
> > > > amdgpu_pm_acpi_event_handler, but I only know for certain that this
> > > > works
> > > > for my GPU.
> > >
> > > I don't agree with that. amdgpu_dpm is generic between all supported HW
> > > generations and shouldn't contain HW generation specific code. Also, it
> > > clearly
> > > doesn't work the same way on every GPU generation, so we shouldn't
> > > generalize.
> > >
> > > Furthermore, we should minimize the amount of messages we send to the
> SMU,
> > > so
> > > we shouldn't send the RunningOnAC message every time we recompute the
> > > clocks,
> > > only when it actually switches to AC.
> > >
> > > > 2. The ATOM_PP_PLATFORM_CAP_HARDWAREDC flag is enabled for my GPU,
> > >
> > > causing
> > >
> > > > PPSMC_MSG_RunningOnAC to never be sent. Either the flag is enabled
> > > > erroneously, or we're interpreting its intended usage incorrectly.
> > >
> > > It's hard to judge that without having access to the hardware or docs.
> > > Are you actually sure that the PPSMC_MSG_RunningOnAC is necessary on
> your
> > > laptop? Isn't it enough to just re-compute the clocks?
> > >
> > > Can you check what exactly is the value of adev->pm.dpm.platform_caps
> on
> > > your
> > > laptop? Maybe we are looking at the wrong flag, or maybe the HARDWAREDC
> > > flag
> > > only refers to the AC->DC transition and not the DC->AC transition.
> > >
> > > This is just guesswork on my part, but maybe we should look at the
> > > SBIOSPOWERSOURCE flag instead, which is explained in pptable_v1_0.h:
> > > /* This cap indicates whether power source notificaiton is done by
> SBIOS
> > > directly. */
> > > Can you check if this flag is set on your laptop?
> > >
> > > Thanks & best regards,
> > > Timur
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 9499 bytes --]