[PATCH] drm/amd/pm/smu7: Don't send VddC_Request on CI

[PATCH] drm/amd/pm/smu7: Don't send VddC_Request on CI

[Petr Belyaev]

smu7_upload_dpm_level_enable_mask() calls
smu7_apply_minimum_dce_voltage_request() unconditionally, which sends
PPSMC_MSG_VddC_Request to the SMC. CI SMC firmware does not implement
that message: it is only defined in smu7_ppsmc.h, tonga_ppsmc.h and
fiji_ppsmc.h, and there is no CI equivalent. The SMC therefore never
writes SMC_RESP, PHM_WAIT_FIELD_UNEQUAL() spins until it gives up, and
every call burns the full ~1.9s response timeout.

Nothing downstream notices, because ci_send_msg_to_smc() returns 0
regardless of the outcome. The only effects are the delay and

  amdgpu: failed to send message 15f ret is 0

in dmesg. On a Radeon R7 260X (BONAIRE, 1002:6658) this is 40 messages
per boot: 32 during the boot-time modeset, which becomes ~59s of blank
screen, and 8 more on every DPMS wake, adding ~15s before the display
comes back.

Commit 0138610c1413 ("drm/amd/pm/smu7: Fix SMU7 voltage dependency on
display clock") extended this feature to CI, which the previous
implementation had deliberately excluded -- the old call site was
guarded by pp_table_version == PP_TABLE_V1 with an adjacent comment
reading "TO DO for v0 iceland and Ci". That commit was verified on a
Radeon R9 M380, which is VI, so the CI path went untested.

Restore the PP_TABLE_V1 condition. With it back the failed messages
disappear entirely and both the boot modeset and the monitor wake are
immediate.

Fixes: 0138610c1413 ("drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock")
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5678
Cc: stable@vger.kernel.org
Signed-off-by: Petr Belyaev <upcfrost@gmail.com>
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

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 6529a91..aadf6d5 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
@@ -3189,7 +3189,11 @@ static int smu7_upload_dpm_level_enable_mask(struct pp_hwmgr *hwmgr)
 {
 	struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
 
-	smu7_apply_minimum_dce_voltage_request(hwmgr);
+	/* CI SMC firmware does not implement PPSMC_MSG_VddC_Request, and each
+	 * attempt costs a full SMC response timeout.
+	 */
+	if (hwmgr->pp_table_version == PP_TABLE_V1)
+		smu7_apply_minimum_dce_voltage_request(hwmgr);
 
 	if (!data->sclk_dpm_key_disabled) {
 		if (data->dpm_level_enable_mask.sclk_dpm_enable_mask)
-- 
2.54.0
:wqa

Re: [PATCH] drm/amd/pm/smu7: Don't send VddC_Request on CI

[Timur Kristóf]

On Monday, August 24, 2026 4:47:14 PM Central European Summer Time Petr 
Belyaev wrote:
> smu7_upload_dpm_level_enable_mask() calls
> smu7_apply_minimum_dce_voltage_request() unconditionally, which sends
> PPSMC_MSG_VddC_Request to the SMC. CI SMC firmware does not implement
> that message: it is only defined in smu7_ppsmc.h, tonga_ppsmc.h and
> fiji_ppsmc.h, and there is no CI equivalent. The SMC therefore never
> writes SMC_RESP, PHM_WAIT_FIELD_UNEQUAL() spins until it gives up, and
> every call burns the full ~1.9s response timeout.

Hi,

I'm sorry but this is wrong.
I added the VDDC request specifically to solve an issue with a Bonaire GPU.
That system will boot into a black screen without requesting a high enough 
voltage for the display engine. This patch would regress that.

> 
> Nothing downstream notices, because ci_send_msg_to_smc() returns 0
> regardless of the outcome. The only effects are the delay and
> 
>   amdgpu: failed to send message 15f ret is 0
> 
> in dmesg. On a Radeon R7 260X (BONAIRE, 1002:6658) this is 40 messages
> per boot: 32 during the boot-time modeset, which becomes ~59s of blank
> screen, and 8 more on every DPMS wake, adding ~15s before the display
> comes back.

How do you reproduce this issue, and on which kernel version?
I've tested this patch on two different Bonaire chips and a Hawaii chip, and 
haven't seen this error message. In fact I am running an R9 390X right now and 
I don't see this error message in my logs.

> 
> Commit 0138610c1413 ("drm/amd/pm/smu7: Fix SMU7 voltage dependency on
> display clock") extended this feature to CI, which the previous
> implementation had deliberately excluded -- the old call site was
> guarded by pp_table_version == PP_TABLE_V1 with an adjacent comment
> reading "TO DO for v0 iceland and Ci". That commit was verified on a
> Radeon R9 M380, which is VI, so the CI path went untested.

The CI path definitely did not go untested.
R9 M380 is Bonaire (it's in an old iMac).
You can see all the details here:
https://gitlab.freedesktop.org/drm/amd/-/work_items/3425#note_3338643

Best regards,
Timur

Re: [PATCH] drm/amd/pm/smu7: Don't send VddC_Request on CI

[Petr Belyaev]

Hi,

You're right, and I withdraw the patch - hadn't considered that gating
it off would regress the systems it was added for.
Apologies also for the M380 claim; I thought it was VI from the commit
message rather than checking.

To reproduce:
Stock 6.18.41, Bonaire XTX 1002:6658 rev 00 (XFX 1682:7260), VBIOS
113-260XT-HY12832-D5-2G-10, SMC firmware 11.35.0 from bonaire_smc.bin.
DC is not enabled here (amdgpu.dc left at the default).
I'm getting roughly 40 "failed to send message 15f ret is 0" messages
per boot, ~1.9s each.
gitlab: https://gitlab.freedesktop.org/drm/amd/-/work_items/5678

One more observation: Your MCLK DPM quirk does fire on this card - i
see the msg 'disabling MCLK DPM on quirky ASIC' in dmesg.

Would be happy to test anything that might solve the problem.

Best regards,
Petr


On Mon, Aug 24, 2026 at 5:07 PM Timur Kristóf <timur.kristof@gmail.com> wrote:
>
> On Monday, August 24, 2026 4:47:14 PM Central European Summer Time Petr
> Belyaev wrote:
> > smu7_upload_dpm_level_enable_mask() calls
> > smu7_apply_minimum_dce_voltage_request() unconditionally, which sends
> > PPSMC_MSG_VddC_Request to the SMC. CI SMC firmware does not implement
> > that message: it is only defined in smu7_ppsmc.h, tonga_ppsmc.h and
> > fiji_ppsmc.h, and there is no CI equivalent. The SMC therefore never
> > writes SMC_RESP, PHM_WAIT_FIELD_UNEQUAL() spins until it gives up, and
> > every call burns the full ~1.9s response timeout.
>
> Hi,
>
> I'm sorry but this is wrong.
> I added the VDDC request specifically to solve an issue with a Bonaire GPU.
> That system will boot into a black screen without requesting a high enough
> voltage for the display engine. This patch would regress that.
>
> >
> > Nothing downstream notices, because ci_send_msg_to_smc() returns 0
> > regardless of the outcome. The only effects are the delay and
> >
> >   amdgpu: failed to send message 15f ret is 0
> >
> > in dmesg. On a Radeon R7 260X (BONAIRE, 1002:6658) this is 40 messages
> > per boot: 32 during the boot-time modeset, which becomes ~59s of blank
> > screen, and 8 more on every DPMS wake, adding ~15s before the display
> > comes back.
>
> How do you reproduce this issue, and on which kernel version?
> I've tested this patch on two different Bonaire chips and a Hawaii chip, and
> haven't seen this error message. In fact I am running an R9 390X right now and
> I don't see this error message in my logs.
>
> >
> > Commit 0138610c1413 ("drm/amd/pm/smu7: Fix SMU7 voltage dependency on
> > display clock") extended this feature to CI, which the previous
> > implementation had deliberately excluded -- the old call site was
> > guarded by pp_table_version == PP_TABLE_V1 with an adjacent comment
> > reading "TO DO for v0 iceland and Ci". That commit was verified on a
> > Radeon R9 M380, which is VI, so the CI path went untested.
>
> The CI path definitely did not go untested.
> R9 M380 is Bonaire (it's in an old iMac).
> You can see all the details here:
> https://gitlab.freedesktop.org/drm/amd/-/work_items/3425#note_3338643
>
> Best regards,
> Timur
>
>

Re: [PATCH] drm/amd/pm/smu7: Don't send VddC_Request on CI

[Timur Kristóf]

On Monday, August 24, 2026 6:11:48 PM Central European Summer Time Petr 
Belyaev wrote:
> Hi,
> 
> You're right, and I withdraw the patch - hadn't considered that gating
> it off would regress the systems it was added for.
> Apologies also for the M380 claim; I thought it was VI from the commit
> message rather than checking.

Unfortunately, it is difficult to find information about which graphics card uses 
which GPU exactly, and the information online (Wikipedia, Techpowerup) is 
sometimes wrong.

> To reproduce:
> Stock 6.18.41, Bonaire XTX 1002:6658 rev 00 (XFX 1682:7260), VBIOS
> 113-260XT-HY12832-D5-2G-10, SMC firmware 11.35.0 from bonaire_smc.bin.
> DC is not enabled here (amdgpu.dc left at the default).
> I'm getting roughly 40 "failed to send message 15f ret is 0" messages
> per boot, ~1.9s each.
> gitlab: https://gitlab.freedesktop.org/drm/amd/-/work_items/5678

Thank you Petr. Let's continue the conversation on the GitLab.

> 
> On Mon, Aug 24, 2026 at 5:07 PM Timur Kristóf <timur.kristof@gmail.com> 
wrote:
> > On Monday, August 24, 2026 4:47:14 PM Central European Summer Time Petr
> > 
> > Belyaev wrote:
> > > smu7_upload_dpm_level_enable_mask() calls
> > > smu7_apply_minimum_dce_voltage_request() unconditionally, which sends
> > > PPSMC_MSG_VddC_Request to the SMC. CI SMC firmware does not implement
> > > that message: it is only defined in smu7_ppsmc.h, tonga_ppsmc.h and
> > > fiji_ppsmc.h, and there is no CI equivalent. The SMC therefore never
> > > writes SMC_RESP, PHM_WAIT_FIELD_UNEQUAL() spins until it gives up, and
> > > every call burns the full ~1.9s response timeout.
> > 
> > Hi,
> > 
> > I'm sorry but this is wrong.
> > I added the VDDC request specifically to solve an issue with a Bonaire
> > GPU.
> > That system will boot into a black screen without requesting a high enough
> > voltage for the display engine. This patch would regress that.
> > 
> > > Nothing downstream notices, because ci_send_msg_to_smc() returns 0
> > > regardless of the outcome. The only effects are the delay and
> > > 
> > >   amdgpu: failed to send message 15f ret is 0
> > > 
> > > in dmesg. On a Radeon R7 260X (BONAIRE, 1002:6658) this is 40 messages
> > > per boot: 32 during the boot-time modeset, which becomes ~59s of blank
> > > screen, and 8 more on every DPMS wake, adding ~15s before the display
> > > comes back.
> > 
> > How do you reproduce this issue, and on which kernel version?
> > I've tested this patch on two different Bonaire chips and a Hawaii chip,
> > and haven't seen this error message. In fact I am running an R9 390X
> > right now and I don't see this error message in my logs.
> > 
> > > Commit 0138610c1413 ("drm/amd/pm/smu7: Fix SMU7 voltage dependency on
> > > display clock") extended this feature to CI, which the previous
> > > implementation had deliberately excluded -- the old call site was
> > > guarded by pp_table_version == PP_TABLE_V1 with an adjacent comment
> > > reading "TO DO for v0 iceland and Ci". That commit was verified on a
> > > Radeon R9 M380, which is VI, so the CI path went untested.
> > 
> > The CI path definitely did not go untested.
> > R9 M380 is Bonaire (it's in an old iMac).
> > You can see all the details here:
> > https://gitlab.freedesktop.org/drm/amd/-/work_items/3425#note_3338643
> > 
> > Best regards,
> > Timur