[PATCH] drm/amd/pm: use the VBIOS trained UCLK levels on the MacBookPro16,1

[PATCH] drm/amd/pm: use the VBIOS trained UCLK levels on the MacBookPro16,1

[Andre Eikmeyer]

The Radeon Pro 5300M and 5500M of the MacBookPro16,1 (Navi 14 boards
1002:7340/106b:0210 and 1002:7340/106b:020f) stop answering SMU messages
as soon as UCLK switches into its third level. This happens at boot or
at the latest under dGPU load and ends in a CPU CATERR that resets the
machine.

Apple's VBIOS trains the UMC p-state sets at 95, 496, 598 and 736 MHz
(umc_info v3.3), but its pptable lists 95, 496, 736 and 750 MHz. Level 2
then runs 736 MHz on a set trained at 598 MHz.

Take the UCLK levels of these boards from umc_info.

Tested on three MacBookPro16,1, two with the 5500M and one with the 5300M.

Cc: stable@vger.kernel.org
Signed-off-by: Andre Eikmeyer <dev@deq.rocks>
---
 .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 2d0508861..63b773252 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -470,6 +470,60 @@ static int navi10_store_powerplay_table(struct smu_context *smu)
 	return 0;
 }
 
+static bool navi14_needs_trained_uclk(struct amdgpu_device *adev)
+{
+	struct pci_dev *pdev = adev->pdev;
+
+	return pdev->vendor == PCI_VENDOR_ID_ATI &&
+		pdev->device == 0x7340 &&
+		pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE &&
+		(pdev->subsystem_device == 0x020f ||
+		 pdev->subsystem_device == 0x0210);
+}
+
+/*
+ * The pptable of these boards lists other UCLK levels than the VBIOS trained
+ * the UMC p-state sets at, and the SMU hangs switching into such a level.
+ */
+static void navi14_use_trained_uclk_levels(struct smu_context *smu)
+{
+	struct amdgpu_device *adev = smu->adev;
+	PPTable_t *pptable = smu->smu_table.driver_pptable;
+	struct atom_umc_info_v3_3 *umc_info;
+	uint16_t trained[NUM_UCLK_DPM_LEVELS];
+	uint16_t size;
+	uint8_t frev, crev;
+	int index, i;
+
+	if (!navi14_needs_trained_uclk(adev) ||
+	    pptable->DpmDescriptor[PPCLK_UCLK].NumDiscreteLevels != NUM_UCLK_DPM_LEVELS)
+		return;
+
+	index = get_index_into_master_table(atom_master_list_of_data_tables_v2_1,
+					    umc_info);
+	if (amdgpu_atombios_get_data_table(adev, index, &size, &frev, &crev,
+					   (uint8_t **)&umc_info) ||
+	    frev != 3 || crev != 3 || size < sizeof(*umc_info))
+		return;
+
+	for (i = 0; i < NUM_UCLK_DPM_LEVELS; i++) {
+		trained[i] = le32_to_cpu(umc_info->pstate_uclk_10khz[MAX_UCLK_DPM_LEVEL - i]) / 100;
+		if (!trained[i] || (i && trained[i] <= trained[i - 1]))
+			return;
+	}
+
+	for (i = 0; i < NUM_UCLK_DPM_LEVELS; i++) {
+		if (pptable->FreqTableUclk[i] == trained[i])
+			continue;
+		dev_info(adev->dev, "UCLK level %d: %u MHz -> %u MHz, as trained by the VBIOS\n",
+			 i, pptable->FreqTableUclk[i], trained[i]);
+		pptable->FreqTableUclk[i] = trained[i];
+	}
+
+	pptable->DcModeMaxFreq[PPCLK_UCLK] = min(pptable->DcModeMaxFreq[PPCLK_UCLK],
+						 trained[MAX_UCLK_DPM_LEVEL]);
+}
+
 static int navi10_setup_pptable(struct smu_context *smu)
 {
 	int ret = 0;
@@ -482,6 +536,8 @@ static int navi10_setup_pptable(struct smu_context *smu)
 	if (ret)
 		return ret;
 
+	navi14_use_trained_uclk_levels(smu);
+
 	ret = navi10_append_powerplay_table(smu);
 	if (ret)
 		return ret;

base-commit: 77f548b127c6de34ce271fa09ba270cb1ef9f2da
-- 
2.56.0

Re: [PATCH] drm/amd/pm: use the VBIOS trained UCLK levels on the MacBookPro16,1

[James Skillen]

On Sat, 24 Oct 2026 18:21:09 +0200, Andre Eikmeyer wrote:
> The Radeon Pro 5300M and 5500M of the MacBookPro16,1 (Navi 14 boards
> 1002:7340/106b:0210 and 1002:7340/106b:020f) stop answering SMU messages
> as soon as UCLK switches into its third level.

This is the hang reported in drm/amd issue 6005, which has the
umc_info analysis and test results from both boards:

  https://gitlab.freedesktop.org/drm/amd/-/work_items/6005

Could v2 carry a Closes: tag for it?

I tested the patch on a MacBookPro16,1 with the Pro 5300M (1002:7340
rev 0x43, 106b:0210, VBIOS 113-D32207P1-019), on linux-t2 7.2.11 (Arch
v7.2.11-arch1 plus the t2linux patches) with this patch on top. The
userspace pp_table upload from the issue was disabled for these boots,
so the corrected levels came from the patch alone.

All at DPM auto unless noted:

 - both "UCLK level ..." lines at boot and again after every resume,
   pp_dpm_mclk 95/496/598/736
 - forced pp_dpm_mclk switches through every level transition, idle
   and under memtest_vulkan load (57 switches, every 3 s): all landed
 - UCLK pinned at level 2 (598 MHz): llama.cpp benchmark and 180 s of
   memtest_vulkan, no errors
 - 60 min soak of llama.cpp runs with idle gaps, and 30 min of normal
   desktop use with the soak running
 - 8 deep suspend/resume cycles (rtcwake, lid, systemctl suspend)

I ran these with the internal panel on the iGPU and again with the
Radeon driving it (apple-gmux force_igd=n). No "SMU: No response", GPU
reset, ring timeout or DC errors in any of them. With the stock driver,
level 2 hung within seconds.

For the runs with the Radeon on the panel I also had
amdgpu.dcdebugmask=0x1. That is for a separate DC issue (the MPC pipe
split on the 3072x1920 eDP plane makes DRAM clock change unsupported,
so UCLK stays at the top level). It is not related to this patch and
I will report it separately.

Tested-by: James Skillen <jahs@jahs.net> # MacBookPro16,1, Pro 5300M (106b:0210)

The testing above and this reply were prepared with help from
claude-opus-5-5; I have checked the results and the text.

Thanks,
James

Re: [PATCH] drm/amd/pm: use the VBIOS trained UCLK levels on the MacBookPro16, 1

[Alex Deucher]

On Tue, Nov 3, 2026 at 3:21 AM James Skillen <jahs@jahs.net> wrote:
>
> On Sat, 24 Oct 2026 18:21:09 +0200, Andre Eikmeyer wrote:
> > The Radeon Pro 5300M and 5500M of the MacBookPro16,1 (Navi 14 boards
> > 1002:7340/106b:0210 and 1002:7340/106b:020f) stop answering SMU messages
> > as soon as UCLK switches into its third level.
>
> This is the hang reported in drm/amd issue 6005, which has the
> umc_info analysis and test results from both boards:
>
>   https://gitlab.freedesktop.org/drm/amd/-/work_items/6005
>
> Could v2 carry a Closes: tag for it?
>
> I tested the patch on a MacBookPro16,1 with the Pro 5300M (1002:7340
> rev 0x43, 106b:0210, VBIOS 113-D32207P1-019), on linux-t2 7.2.11 (Arch
> v7.2.11-arch1 plus the t2linux patches) with this patch on top. The
> userspace pp_table upload from the issue was disabled for these boots,
> so the corrected levels came from the patch alone.

Can you try this patch instead:
https://patchwork.freedesktop.org/patch/765668/?series=174386&rev=2

Alex

>
> All at DPM auto unless noted:
>
>  - both "UCLK level ..." lines at boot and again after every resume,
>    pp_dpm_mclk 95/496/598/736
>  - forced pp_dpm_mclk switches through every level transition, idle
>    and under memtest_vulkan load (57 switches, every 3 s): all landed
>  - UCLK pinned at level 2 (598 MHz): llama.cpp benchmark and 180 s of
>    memtest_vulkan, no errors
>  - 60 min soak of llama.cpp runs with idle gaps, and 30 min of normal
>    desktop use with the soak running
>  - 8 deep suspend/resume cycles (rtcwake, lid, systemctl suspend)
>
> I ran these with the internal panel on the iGPU and again with the
> Radeon driving it (apple-gmux force_igd=n). No "SMU: No response", GPU
> reset, ring timeout or DC errors in any of them. With the stock driver,
> level 2 hung within seconds.
>
> For the runs with the Radeon on the panel I also had
> amdgpu.dcdebugmask=0x1. That is for a separate DC issue (the MPC pipe
> split on the 3072x1920 eDP plane makes DRAM clock change unsupported,
> so UCLK stays at the top level). It is not related to this patch and
> I will report it separately.
>
> Tested-by: James Skillen <jahs@jahs.net> # MacBookPro16,1, Pro 5300M (106b:0210)
>
> The testing above and this reply were prepared with help from
> claude-opus-5-5; I have checked the results and the text.
>
> Thanks,
> James

Re: [PATCH] drm/amd/pm: use the VBIOS trained UCLK levels on the MacBookPro16,1

[James Skillen]

Hi Alex,

On Tue, 3 Nov 2026 09:35:29 -0500, Alex Deucher wrote:
> Can you try this patch instead:
> https://patchwork.freedesktop.org/patch/765668/?series=174386&rev=2

Many thanks for following this up, and for checking with the Windows
team.

I tested v5 ("drm/amd/pm: defer UCLK DPM on selected Apple Navi
GPUs") on the same MacBookPro16,1 (Pro 5300M, 1002:7340 rev 0x43,
106b:0210, VBIOS 113-D32207P1-019). Kernel 7.3.3 plus the t2linux
patches, v5 applied unmodified. Its navi10_ppt.c differs from
amd-staging-drm-next 178d00b only in the error returns of
navi10_force_clk_levels ("return 0" vs "return ret"); none of these
tests took an error path there. Panel on the Radeon, dcdebugmask=0x1
as before, and SMU messages logged with
amdgpu.dyndbg="file smu_cmn.c +p".

v5 works as described: UCLK is left out of the allowed mask at init
(SetAllowedFeaturesMaskLow 0xa7dfbfb3, stock 0xa7dfbfbb) and enabled
with EnableSmuFeaturesLow(0x8) about 1.2 s after DC init. It boots
cleanly, as stock does on this board. It does not change the UCLK
levels, and the hang is in level 2:

                     UCLK levels       UCLK level 2 pinned at idle,
                     (MHz)             ~5 min after boot
  stock 7.3.3        95/496/736/750    SMU no response after 3.4 s,
                                       GPU reset fails, machine hangs
  v5                 95/496/736/750    SMU no response after 3.5 s,
                                       same
  v5 + trained       95/496/598/736    ok, also under load (below)
  levels

"Machine hangs": a heartbeat sent over the network every 5 s stopped
within ~10 s of the failed GPU reset in both runs, so it was the whole
machine, not only the display.

v5, SMU messages around the pin:

  [311.750451] smu send message: SetSoftMaxByFreq(27), resp: 0x00000001
               in params:000202e0
  [311.750635] smu send message: SetSoftMinByFreq(26), resp: 0x00000001
               in params:000202e0
  [315.231058] SMU: No response msg_reg: 12 resp_reg: 0

For the last row the levels came from a pp_table upload with the
umc_info training points, the values Andre's patch sets in the
driver. v5's late enable ran again after the SMU restart. Forced
switches through every level transition at idle, level 2 pinned under
llama.cpp and memtest_vulkan, memtest_vulkan with forced switches
every 3 s, and a load run at DPM auto all passed, with no SMU or ring
errors. So on this board v5 and the corrected levels work together.

The root cause is in the board's VBIOS: its pptable UCLK levels
(736/750 MHz) don't match the umc_info training points (598/736 MHz).
A corrected VBIOS would be the clean fix; failing that, a driver check
that uses umc_info when the two disagree (a no-op on a correct VBIOS)
seems the practical one.

The testing above and this reply were prepared with help from
claude-opus-5-5; I have checked the results and the text.

Kind regards,
James

Re: [PATCH] drm/amd/pm: use the VBIOS trained UCLK levels on the MacBookPro16, 1

[Aditya Garg]

On 03/11/26 20:05, Alex Deucher wrote:
> On Tue, Nov 3, 2026 at 3:21 AM James Skillen <jahs@jahs.net> wrote:
>>
>> On Sat, 24 Oct 2026 18:21:09 +0200, Andre Eikmeyer wrote:
>>> The Radeon Pro 5300M and 5500M of the MacBookPro16,1 (Navi 14 boards
>>> 1002:7340/106b:0210 and 1002:7340/106b:020f) stop answering SMU messages
>>> as soon as UCLK switches into its third level.
>>
>> This is the hang reported in drm/amd issue 6005, which has the
>> umc_info analysis and test results from both boards:
>>
>>   https://gitlab.freedesktop.org/drm/amd/-/work_items/6005
>>
>> Could v2 carry a Closes: tag for it?
>>
>> I tested the patch on a MacBookPro16,1 with the Pro 5300M (1002:7340
>> rev 0x43, 106b:0210, VBIOS 113-D32207P1-019), on linux-t2 7.2.11 (Arch
>> v7.2.11-arch1 plus the t2linux patches) with this patch on top. The
>> userspace pp_table upload from the issue was disabled for these boots,
>> so the corrected levels came from the patch alone.
> 
> Can you try this patch instead:
> https://patchwork.freedesktop.org/patch/765668/?series=174386&rev=2
> 
> Alex


The patch is the above link is a vibe coded mess that sometimes works, sometimes won't with appropriate discussion done by the author himself. The once sent by Andre in this series is clean, simple and logical.

Reviewed-by: Aditya Garg <aditya.garg@linux.dev>
Tested-by: Aditya Garg <aditya.garg@linux.dev> # MacBookPro16,1 with AMD Radeon Pro 5300M

Support for more models as claimed by the vibe coded patch should be done after appropriate feedback from the users in another series. Unfortunately after every few kernel versions the most number of regressions we face are from AMD GPU drivers and untested patches are the cause everytime.