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

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.

---
 .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)

index 2d0508861..63b773252 100644
@@ -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

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.

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

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

Alex

Hi Alex,

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

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.

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.