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