[PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Ed Schofield]

From: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>

Some Apple Navi GPUs intermittently time out during SMU initialization
when EnableAllSmuFeatures includes UCLK DPM. Leave UCLK out of that early
request and enable it from Navi post-init, after display hardware init
and before the UMC workaround and UMD clock setup.

Read back the enabled features before rebuilding the memory clock table
and sustainable clock limits. Also check the PPT memory states used by
display initialization before late enablement. Keep memory-voltage DPM
and respect the user's memory-DPM setting and the secure Navi 10 exclusion.

Limit this workaround to Apple 7340/0218 revision 41, 7340/0219, and
731b/021a revision 40. Revisions and PCI IDs here are hexadecimal. The
underlying initialization dependency behind the timing sensitivity is
still unknown.

This builds on Atharva Tiwari's submitted 0219 delayed-UCLK patch
and Guna's diagnosis. Ed Schofield moved the enable point into the
Navi callback, added state validation and clock-table refresh, and
extended the board matching.
Independent tests of the related T2 implementation support improved boot
reliability on 0219 and 021a; those are not tests of this exact AMD patch.

Link: https://lore.kernel.org/amd-gfx/20260824190409.1724-1-atharvatiwarilinuxdev@gmail.com/
Link: https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5637976466
Link: https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5645652752
Assisted-by: Codex:GPT-6
Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
Co-developed-by: Ed Schofield <ed@aicharmers.com>
Signed-off-by: Ed Schofield <ed@aicharmers.com>
---
Hi Alex, hi Atharva,

Here is v4 of the delayed-UCLK workaround. Atharva is credited as the
author in `From:`, with my rework credited through `Co-developed-by:`.
The local development history starts from Atharva's original 0219
submission [1], followed by my move to the Navi post-init callback,
state validation, clock-table refresh and additional board support. This
export is a single replacement patch against AMD staging at `8a4e96cf2`;
it is not an incremental patch to apply on top of v2 or Atharva's
original patch. (V3 was a local revision that I didn't submit to this
list.)

Atharva, I agree that display initialization may explain the timing
dependency. This patch already enables UCLK after display hardware
initialization on the normal probe path. It is intended as a targeted
workaround for the reported boot failures; it does not establish the
underlying cause or address native 5K support. Could you share the exact
initialization-ordering diff, kernel version and GPU IDs from your
experiment? In the AMD staging tree used for this patch,
`dce_v10_0_early_init()` handles Tonga/Fiji, while these Navi boards use
the DCN path.

My goal is to stop the intermittent boot failures on my iMac (0218) and
other affected machines. Testing of my related T2 candidate in PR 61
[2], which was based on my local v3, is encouraging:

- Matt Olney's report on 021a [3] records internal-display boot success
  improving from 2/10 to 10/10, with mixed restart types.
  External-display results were 4/10 versus 4/5, with uncertain kernel
  selection on the failed candidate attempt.
- Vivek Chauhan's report on 0219 [4] records boot success improving from
  1/5 to 3/3.

These results are from the T2 implementation, not this exact AMD v4
export. The T2 patch stack also includes a separate correction to its
existing fixed allowed-feature mask on 0219, which clean AMD does not
need and this patch does not contain. The results support improved boot
reliability on these machines, but do not establish full performance or
reliability across all display configurations.

Compared with public v2, v4 adds 731b/021a revision 40, preserves the
existing secure-Navi-10 exclusion and generalizes the helper names. It
retains 7340/0218 revision 41 and 7340/0219. All IDs and revisions here
are hexadecimal.

Compared with my local v3 / T2 Linux PR #61, v4 excludes 020f: 3v3nFloW
reported that initialization completed but the machine subsequently hung
under load [5]. Their follow-up testing with a fixed memory-clock level
[6] suggests that memory-clock changes cause the hang, but doesn't
establish whether GPU load or display activity triggers it. I've also
excluded 021b from this version, which we don't yet have testing results
for.

Local build and host checks pass. I am currently travelling without my
iMac and have no new v4 hardware results, but I am submitting this
version for merging, with the workaround limited to the three board
matches supported by the existing evidence from the volunteer testers
mentioned above.

Alex, this patch replaces v2 and applies directly to the AMD staging
commit identified above.

Thanks,
Ed

[1] https://lore.kernel.org/amd-gfx/20260824190409.1724-1-atharvatiwarilinuxdev@gmail.com/
[2] https://github.com/t2linux/linux-t2-patches/pull/61
[3] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5637976466
[4] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5645652752
[5] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5646139127
[6] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5646438512

v3 was local, not submitted. Since public v2: add the tested 021a/40
match, retain the secure-Navi-10 exclusion, and generalize helper names.
Since local v3: remove 020f (load hangs) and 021b (no testing evidence).
Base: 8a4e96cf2acd1e0340581df100b559f77ad7d855 (AMD staging).
This is a full replacement, not a patch to apply on top of v2.

 .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 100 ++++++++++++++++++
 1 file changed, 100 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 f8ca5eb9a..3ac2a074c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -60,6 +60,37 @@
 
 static int navi10_init_ppt_limits(struct smu_context *smu);
 
+static bool is_asic_secure(struct smu_context *smu);
+
+static bool navi10_apple_needs_late_uclk(struct smu_context *smu)
+{
+	struct amdgpu_device *adev = smu->adev;
+	struct pci_dev *pdev = adev->pdev;
+
+	if (pdev->vendor != PCI_VENDOR_ID_ATI ||
+	    pdev->subsystem_vendor != PCI_VENDOR_ID_APPLE ||
+	    !(adev->pm.pp_feature & PP_MCLK_DPM_MASK))
+		return false;
+
+	/* Preserve the existing secure Navi 10 memory-DPM exclusion. */
+	if (is_asic_secure(smu) &&
+	    amdgpu_ip_version(adev, MP1_HWIP, 0) == IP_VERSION(11, 0, 0) &&
+	    adev->rev_id == 0)
+		return false;
+
+	switch (pdev->device) {
+	case 0x7340:
+		return (pdev->subsystem_device == 0x0218 &&
+			pdev->revision == 0x41) ||
+		       pdev->subsystem_device == 0x0219;
+	case 0x731b:
+		return pdev->subsystem_device == 0x021a &&
+		       pdev->revision == 0x40;
+	default:
+		return false;
+	}
+}
+
 static const struct smu_feature_bits navi10_dpm_features = {
 	.bits = {
 		SMU_FEATURE_BIT_INIT(FEATURE_DPM_PREFETCHER_BIT),
@@ -356,6 +387,11 @@ navi10_init_allowed_features(struct smu_context *smu)
 		smu_feature_list_set_bit(smu, SMU_FEATURE_LIST_ALLOWED, FEATURE_MEM_MVDD_SCALING_BIT);
 	}
 
+	/* Defer UCLK on the selected Apple boards until IP late init. */
+	if (navi10_apple_needs_late_uclk(smu))
+		smu_feature_list_clear_bit(smu, SMU_FEATURE_LIST_ALLOWED,
+					   FEATURE_DPM_UCLK_BIT);
+
 	if (is_asic_secure(smu) &&
 	    (amdgpu_ip_version(adev, MP1_HWIP, 0) == IP_VERSION(11, 0, 0)) &&
 	    (adev->rev_id == 0))
@@ -470,6 +506,25 @@ static int navi10_store_powerplay_table(struct smu_context *smu)
 	return 0;
 }
 
+/* DCN20 consumes these PPT states before the post-init UCLK enable. */
+static int navi10_apple_check_uclk_states(struct smu_context *smu)
+{
+	PPTable_t *ppt = smu->smu_table.driver_pptable;
+	unsigned int count, i;
+
+	if (!navi10_apple_needs_late_uclk(smu))
+		return 0;
+
+	count = ppt->DpmDescriptor[PPCLK_UCLK].NumDiscreteLevels;
+	if (!count || count > ARRAY_SIZE(ppt->FreqTableUclk))
+		return -EINVAL;
+	for (i = 0; i < count; i++) {
+		if (!ppt->FreqTableUclk[i])
+			return -EINVAL;
+	}
+	return 0;
+}
+
 static int navi10_setup_pptable(struct smu_context *smu)
 {
 	int ret = 0;
@@ -490,6 +545,10 @@ static int navi10_setup_pptable(struct smu_context *smu)
 	if (ret)
 		return ret;
 
+	ret = navi10_apple_check_uclk_states(smu);
+	if (ret)
+		return ret;
+
 	return navi10_init_ppt_limits(smu);
 }
 
@@ -3219,6 +3278,41 @@ static int navi10_enable_mgpu_fan_boost(struct smu_context *smu)
 					       NULL);
 }
 
+/* IP late init follows display hw_init; refresh clocks before UMC/UMD setup. */
+static int navi10_apple_late_uclk_enable(struct smu_context *smu)
+{
+	struct smu_11_0_dpm_context *dpm = smu->smu_dpm.dpm_context;
+	struct smu_dpm_table *table = &dpm->dpm_tables.uclk_table;
+	PPTable_t *ppt = smu->smu_table.driver_pptable;
+	struct smu_feature_bits enabled;
+	int ret;
+
+	if (!navi10_apple_needs_late_uclk(smu))
+		return 0;
+
+	ret = smu_cmn_feature_set_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT, true);
+	if (ret)
+		return ret;
+	ret = smu_cmn_get_enabled_mask(smu, &enabled);
+	if (ret)
+		return ret;
+	if (!smu_feature_bits_is_set(&enabled, FEATURE_DPM_UCLK_BIT))
+		return -EIO;
+
+	smu_feature_list_set_bit(smu, SMU_FEATURE_LIST_SUPPORTED,
+				 FEATURE_DPM_UCLK_BIT);
+	table->clk_type = SMU_UCLK;
+	ret = smu_v11_0_set_single_dpm_table(smu, SMU_UCLK, table);
+	if (ret)
+		return ret;
+	if (!table->count)
+		return -EINVAL;
+	if (!ppt->DpmDescriptor[PPCLK_UCLK].SnapToDiscrete)
+		table->flags |= SMU_DPM_TABLE_FINE_GRAINED;
+
+	return smu_v11_0_init_max_sustainable_clocks(smu);
+}
+
 static int navi10_post_smu_init(struct smu_context *smu)
 {
 	struct amdgpu_device *adev = smu->adev;
@@ -3227,6 +3321,12 @@ static int navi10_post_smu_init(struct smu_context *smu)
 	if (amdgpu_sriov_vf(adev))
 		return 0;
 
+	ret = navi10_apple_late_uclk_enable(smu);
+	if (ret) {
+		dev_err(adev->dev, "Failed to enable late UCLK DPM: %d\n", ret);
+		return ret;
+	}
+
 	ret = navi10_run_umc_cdr_workaround(smu);
 	if (ret)
 		dev_err(adev->dev, "Failed to apply umc cdr workaround!\n");
-- 
2.43.0

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Alex Deucher]

+ Andre

On Wed, Sep 16, 2026 at 10:51 AM Ed Schofield <ed@aicharmers.com> wrote:
>
> From: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
>
> Some Apple Navi GPUs intermittently time out during SMU initialization
> when EnableAllSmuFeatures includes UCLK DPM. Leave UCLK out of that early
> request and enable it from Navi post-init, after display hardware init
> and before the UMC workaround and UMD clock setup.
>
> Read back the enabled features before rebuilding the memory clock table
> and sustainable clock limits. Also check the PPT memory states used by
> display initialization before late enablement. Keep memory-voltage DPM
> and respect the user's memory-DPM setting and the secure Navi 10 exclusion.
>
> Limit this workaround to Apple 7340/0218 revision 41, 7340/0219, and
> 731b/021a revision 40. Revisions and PCI IDs here are hexadecimal. The
> underlying initialization dependency behind the timing sensitivity is
> still unknown.

@Andre Eikmeyer I think this patch should fix your system as well.
@Atharva Tiwari are you ok with this patch?

Thanks,

Alex

>
> This builds on Atharva Tiwari's submitted 0219 delayed-UCLK patch
> and Guna's diagnosis. Ed Schofield moved the enable point into the
> Navi callback, added state validation and clock-table refresh, and
> extended the board matching.
> Independent tests of the related T2 implementation support improved boot
> reliability on 0219 and 021a; those are not tests of this exact AMD patch.
>
> Link: https://lore.kernel.org/amd-gfx/20260824190409.1724-1-atharvatiwarilinuxdev@gmail.com/
> Link: https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5637976466
> Link: https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5645652752
> Assisted-by: Codex:GPT-6
> Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
> Co-developed-by: Ed Schofield <ed@aicharmers.com>
> Signed-off-by: Ed Schofield <ed@aicharmers.com>
> ---
> Hi Alex, hi Atharva,
>
> Here is v4 of the delayed-UCLK workaround. Atharva is credited as the
> author in `From:`, with my rework credited through `Co-developed-by:`.
> The local development history starts from Atharva's original 0219
> submission [1], followed by my move to the Navi post-init callback,
> state validation, clock-table refresh and additional board support. This
> export is a single replacement patch against AMD staging at `8a4e96cf2`;
> it is not an incremental patch to apply on top of v2 or Atharva's
> original patch. (V3 was a local revision that I didn't submit to this
> list.)
>
> Atharva, I agree that display initialization may explain the timing
> dependency. This patch already enables UCLK after display hardware
> initialization on the normal probe path. It is intended as a targeted
> workaround for the reported boot failures; it does not establish the
> underlying cause or address native 5K support. Could you share the exact
> initialization-ordering diff, kernel version and GPU IDs from your
> experiment? In the AMD staging tree used for this patch,
> `dce_v10_0_early_init()` handles Tonga/Fiji, while these Navi boards use
> the DCN path.
>
> My goal is to stop the intermittent boot failures on my iMac (0218) and
> other affected machines. Testing of my related T2 candidate in PR 61
> [2], which was based on my local v3, is encouraging:
>
> - Matt Olney's report on 021a [3] records internal-display boot success
>   improving from 2/10 to 10/10, with mixed restart types.
>   External-display results were 4/10 versus 4/5, with uncertain kernel
>   selection on the failed candidate attempt.
> - Vivek Chauhan's report on 0219 [4] records boot success improving from
>   1/5 to 3/3.
>
> These results are from the T2 implementation, not this exact AMD v4
> export. The T2 patch stack also includes a separate correction to its
> existing fixed allowed-feature mask on 0219, which clean AMD does not
> need and this patch does not contain. The results support improved boot
> reliability on these machines, but do not establish full performance or
> reliability across all display configurations.
>
> Compared with public v2, v4 adds 731b/021a revision 40, preserves the
> existing secure-Navi-10 exclusion and generalizes the helper names. It
> retains 7340/0218 revision 41 and 7340/0219. All IDs and revisions here
> are hexadecimal.
>
> Compared with my local v3 / T2 Linux PR #61, v4 excludes 020f: 3v3nFloW
> reported that initialization completed but the machine subsequently hung
> under load [5]. Their follow-up testing with a fixed memory-clock level
> [6] suggests that memory-clock changes cause the hang, but doesn't
> establish whether GPU load or display activity triggers it. I've also
> excluded 021b from this version, which we don't yet have testing results
> for.
>
> Local build and host checks pass. I am currently travelling without my
> iMac and have no new v4 hardware results, but I am submitting this
> version for merging, with the workaround limited to the three board
> matches supported by the existing evidence from the volunteer testers
> mentioned above.
>
> Alex, this patch replaces v2 and applies directly to the AMD staging
> commit identified above.
>
> Thanks,
> Ed
>
> [1] https://lore.kernel.org/amd-gfx/20260824190409.1724-1-atharvatiwarilinuxdev@gmail.com/
> [2] https://github.com/t2linux/linux-t2-patches/pull/61
> [3] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5637976466
> [4] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5645652752
> [5] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5646139127
> [6] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5646438512
>
> v3 was local, not submitted. Since public v2: add the tested 021a/40
> match, retain the secure-Navi-10 exclusion, and generalize helper names.
> Since local v3: remove 020f (load hangs) and 021b (no testing evidence).
> Base: 8a4e96cf2acd1e0340581df100b559f77ad7d855 (AMD staging).
> This is a full replacement, not a patch to apply on top of v2.
>
>  .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 100 ++++++++++++++++++
>  1 file changed, 100 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 f8ca5eb9a..3ac2a074c 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> @@ -60,6 +60,37 @@
>
>  static int navi10_init_ppt_limits(struct smu_context *smu);
>
> +static bool is_asic_secure(struct smu_context *smu);
> +
> +static bool navi10_apple_needs_late_uclk(struct smu_context *smu)
> +{
> +       struct amdgpu_device *adev = smu->adev;
> +       struct pci_dev *pdev = adev->pdev;
> +
> +       if (pdev->vendor != PCI_VENDOR_ID_ATI ||
> +           pdev->subsystem_vendor != PCI_VENDOR_ID_APPLE ||
> +           !(adev->pm.pp_feature & PP_MCLK_DPM_MASK))
> +               return false;
> +
> +       /* Preserve the existing secure Navi 10 memory-DPM exclusion. */
> +       if (is_asic_secure(smu) &&
> +           amdgpu_ip_version(adev, MP1_HWIP, 0) == IP_VERSION(11, 0, 0) &&
> +           adev->rev_id == 0)
> +               return false;
> +
> +       switch (pdev->device) {
> +       case 0x7340:
> +               return (pdev->subsystem_device == 0x0218 &&
> +                       pdev->revision == 0x41) ||
> +                      pdev->subsystem_device == 0x0219;
> +       case 0x731b:
> +               return pdev->subsystem_device == 0x021a &&
> +                      pdev->revision == 0x40;
> +       default:
> +               return false;
> +       }
> +}
> +
>  static const struct smu_feature_bits navi10_dpm_features = {
>         .bits = {
>                 SMU_FEATURE_BIT_INIT(FEATURE_DPM_PREFETCHER_BIT),
> @@ -356,6 +387,11 @@ navi10_init_allowed_features(struct smu_context *smu)
>                 smu_feature_list_set_bit(smu, SMU_FEATURE_LIST_ALLOWED, FEATURE_MEM_MVDD_SCALING_BIT);
>         }
>
> +       /* Defer UCLK on the selected Apple boards until IP late init. */
> +       if (navi10_apple_needs_late_uclk(smu))
> +               smu_feature_list_clear_bit(smu, SMU_FEATURE_LIST_ALLOWED,
> +                                          FEATURE_DPM_UCLK_BIT);
> +
>         if (is_asic_secure(smu) &&
>             (amdgpu_ip_version(adev, MP1_HWIP, 0) == IP_VERSION(11, 0, 0)) &&
>             (adev->rev_id == 0))
> @@ -470,6 +506,25 @@ static int navi10_store_powerplay_table(struct smu_context *smu)
>         return 0;
>  }
>
> +/* DCN20 consumes these PPT states before the post-init UCLK enable. */
> +static int navi10_apple_check_uclk_states(struct smu_context *smu)
> +{
> +       PPTable_t *ppt = smu->smu_table.driver_pptable;
> +       unsigned int count, i;
> +
> +       if (!navi10_apple_needs_late_uclk(smu))
> +               return 0;
> +
> +       count = ppt->DpmDescriptor[PPCLK_UCLK].NumDiscreteLevels;
> +       if (!count || count > ARRAY_SIZE(ppt->FreqTableUclk))
> +               return -EINVAL;
> +       for (i = 0; i < count; i++) {
> +               if (!ppt->FreqTableUclk[i])
> +                       return -EINVAL;
> +       }
> +       return 0;
> +}
> +
>  static int navi10_setup_pptable(struct smu_context *smu)
>  {
>         int ret = 0;
> @@ -490,6 +545,10 @@ static int navi10_setup_pptable(struct smu_context *smu)
>         if (ret)
>                 return ret;
>
> +       ret = navi10_apple_check_uclk_states(smu);
> +       if (ret)
> +               return ret;
> +
>         return navi10_init_ppt_limits(smu);
>  }
>
> @@ -3219,6 +3278,41 @@ static int navi10_enable_mgpu_fan_boost(struct smu_context *smu)
>                                                NULL);
>  }
>
> +/* IP late init follows display hw_init; refresh clocks before UMC/UMD setup. */
> +static int navi10_apple_late_uclk_enable(struct smu_context *smu)
> +{
> +       struct smu_11_0_dpm_context *dpm = smu->smu_dpm.dpm_context;
> +       struct smu_dpm_table *table = &dpm->dpm_tables.uclk_table;
> +       PPTable_t *ppt = smu->smu_table.driver_pptable;
> +       struct smu_feature_bits enabled;
> +       int ret;
> +
> +       if (!navi10_apple_needs_late_uclk(smu))
> +               return 0;
> +
> +       ret = smu_cmn_feature_set_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT, true);
> +       if (ret)
> +               return ret;
> +       ret = smu_cmn_get_enabled_mask(smu, &enabled);
> +       if (ret)
> +               return ret;
> +       if (!smu_feature_bits_is_set(&enabled, FEATURE_DPM_UCLK_BIT))
> +               return -EIO;
> +
> +       smu_feature_list_set_bit(smu, SMU_FEATURE_LIST_SUPPORTED,
> +                                FEATURE_DPM_UCLK_BIT);
> +       table->clk_type = SMU_UCLK;
> +       ret = smu_v11_0_set_single_dpm_table(smu, SMU_UCLK, table);
> +       if (ret)
> +               return ret;
> +       if (!table->count)
> +               return -EINVAL;
> +       if (!ppt->DpmDescriptor[PPCLK_UCLK].SnapToDiscrete)
> +               table->flags |= SMU_DPM_TABLE_FINE_GRAINED;
> +
> +       return smu_v11_0_init_max_sustainable_clocks(smu);
> +}
> +
>  static int navi10_post_smu_init(struct smu_context *smu)
>  {
>         struct amdgpu_device *adev = smu->adev;
> @@ -3227,6 +3321,12 @@ static int navi10_post_smu_init(struct smu_context *smu)
>         if (amdgpu_sriov_vf(adev))
>                 return 0;
>
> +       ret = navi10_apple_late_uclk_enable(smu);
> +       if (ret) {
> +               dev_err(adev->dev, "Failed to enable late UCLK DPM: %d\n", ret);
> +               return ret;
> +       }
> +
>         ret = navi10_run_umc_cdr_workaround(smu);
>         if (ret)
>                 dev_err(adev->dev, "Failed to apply umc cdr workaround!\n");
> --
> 2.43.0

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Atharva Tiwari]

> @Andre Eikmeyer I think this patch should fix your system as well.
> @Atharva Tiwari are you ok with this patch?
> 
> Thanks,
> 
> Alex

No, as i said this is not the reason, and we've already fixed it properly
You can see it here:
https://github.com/t2linux/linux-t2-patches/blob/main/7003-amdgpu-add-support-for-5K.patch
(Adds 5K support and fixes the boot issue).

And for the 16,1 issue (i assume), the only fix is
https://lore.kernel.org/all/20261024162109.307247-1-dev@deq.rocks/

The PPTables provided uclk clock speeds is wrong, thats what causes the issue,
initializing UCLK in post_init wont solve that.

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[André Eikmeyer]

On Thu, 29 Oct 2026 17:57:49 -0400
Alex Deucher <alexdeucher@gmail.com> wrote:

> @Andre Eikmeyer I think this patch should fix your system as well.

Hi Alex,

I guess you have seen it already but the patch doesn't match the 16,1.
Its boards are 7340/020f and 7340/0210, and v4 only matches 0218, 0219
and 021a.

That hang is what I sent a fix for
https://lore.kernel.org/all/20261024162109.307247-1-dev@deq.rocks/

The VBIOS trains the UMC p-states at different frequencies the pp-table
lists. The SMU hangs as soon as UCLK switches into level 2. Deferring
the UCLK enable doesn't change the levels, so the hang just moves from
boot to later under load.

The two patches can coexist after a trivial rebase.

> ...your system...

I need to clarify here. I actually don't own a 16,1. But I maintain a
distro (KaiT2en) that specializes on T2 Macs. So the patches I develop
are extensively tested by the community before submitting. Atharwa is
part of this community. Ed is not, but Atharwa reviewed and tested the
code.

Best,
Andre

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Alex Deucher]

On Fri, Oct 30, 2026 at 7:30 AM André Eikmeyer <dev@deq.rocks> wrote:
>
> On Thu, 29 Oct 2026 17:57:49 -0400
> Alex Deucher <alexdeucher@gmail.com> wrote:
>
> > @Andre Eikmeyer I think this patch should fix your system as well.
>
> Hi Alex,
>
> I guess you have seen it already but the patch doesn't match the 16,1.
> Its boards are 7340/020f and 7340/0210, and v4 only matches 0218, 0219
> and 021a.
>
> That hang is what I sent a fix for
> https://lore.kernel.org/all/20261024162109.307247-1-dev@deq.rocks/
>
> The VBIOS trains the UMC p-states at different frequencies the pp-table
> lists. The SMU hangs as soon as UCLK switches into level 2. Deferring
> the UCLK enable doesn't change the levels, so the hang just moves from
> boot to later under load.
>

It is the same issue.  I don't want two fixes for the same issue. I
just sent an updated version of this patch expanded to cover more
macs.

Alex

> The two patches can coexist after a trivial rebase.
>
> > ...your system...
>
> I need to clarify here. I actually don't own a 16,1. But I maintain a
> distro (KaiT2en) that specializes on T2 Macs. So the patches I develop
> are extensively tested by the community before submitting. Atharwa is
> part of this community. Ed is not, but Atharwa reviewed and tested the
> code.
>
> Best,
> Andre

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Atharva Tiwari]

> It is the same issue.  I don't want two fixes for the same issue. I
> just sent an updated version of this patch expanded to cover more
> macs.
> 
> Alex

How is the problems same exactly?, Does initializing UCLK later change the
PPTable?, and as said this is not even a solution for iMacs, so why are we
still trying to upstream this?, and btw initializing UCLK later with 5K,
makes it not initialize at all, so the patch is just wrong.

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Alex Deucher]

On Tue, Nov 3, 2026 at 10:01 AM Atharva Tiwari
<atharvatiwarilinuxdev@gmail.com> wrote:
>
> > It is the same issue.  I don't want two fixes for the same issue. I
> > just sent an updated version of this patch expanded to cover more
> > macs.
> >
> > Alex
>
> How is the problems same exactly?, Does initializing UCLK later change the
> PPTable?, and as said this is not even a solution for iMacs, so why are we
> still trying to upstream this?, and btw initializing UCLK later with 5K,
> makes it not initialize at all, so the patch is just wrong.

I asked around internally with the windows team about this issue and
was told macs needed to enable UCLK DPM later, but no one was aware of
any uclk dpm patching.

Alex

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[André Eikmeyer]

On Tue, 3 Nov 2026 09:30:34 -0500
Alex Deucher <alexdeucher@gmail.com> wrote:

> It is the same issue.  I don't want two fixes for the same issue.

Understandable, but it is not. Two devs told you the same
independently. 
On another note I reviewed your patch. It only rejects empty or zero
levels. On the 16,1 the pptable levels (736/750 MHz) are non-zero.
Besides other issues in the code, the commit message says the exact
patch wasn't tested, yet v5 extends it to every Apple Navi 1x.
I am sorry but your patch is implausible to me.

Andre 

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Alex Deucher]

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

On Tue, Nov 3, 2026 at 10:25 AM André Eikmeyer <dev@deq.rocks> wrote:
>
> On Tue, 3 Nov 2026 09:30:34 -0500
> Alex Deucher <alexdeucher@gmail.com> wrote:
>
> > It is the same issue.  I don't want two fixes for the same issue.
>
> Understandable, but it is not. Two devs told you the same
> independently.
> On another note I reviewed your patch. It only rejects empty or zero
> levels. On the 16,1 the pptable levels (736/750 MHz) are non-zero.
> Besides other issues in the code, the commit message says the exact
> patch wasn't tested, yet v5 extends it to every Apple Navi 1x.
> I am sorry but your patch is implausible to me.

I forgot to remove the pptable check.  Can you try a simplified
version of the patch?  I think all you need to do is delay the UCLK
DPM enablement until late_init.  Something like the attached patch.

Alex

[-- Attachment #2: 0001-drm-amd-pm-defer-UCLK-DPM-on-selected-Apple-Navi-GPU.patch --]
[-- Type: text/x-patch, Size: 4674 bytes --]

From 0cf8c5010875a2cf2574be2bfb690fd85a0da748 Mon Sep 17 00:00:00 2001
From: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
Date: Wed, 16 Sep 2026 14:40:14 +0000
Subject: [PATCH] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Apple Navi GPUs intermittently time out during SMU initialization
when EnableAllSmuFeatures includes UCLK DPM. Leave UCLK out of that early
request and enable it from Navi post-init, after display hardware init
and before the UMC workaround and UMD clock setup.

Read back the enabled features before rebuilding the memory clock table
and sustainable clock limits. Also check the PPT memory states used by
display initialization before late enablement. Keep memory-voltage DPM
and respect the user's memory-DPM setting and the secure Navi 10 exclusion.

This builds on Atharva Tiwari's submitted 0219 delayed-UCLK patch
and Guna's diagnosis. Ed Schofield moved the enable point into the
Navi callback, added state validation.
Independent tests of the related T2 implementation support improved boot
reliability on 0219 and 021a; those are not tests of this exact AMD patch.

Link: https://lore.kernel.org/amd-gfx/20260824190409.1724-1-atharvatiwarilinuxdev@gmail.com/
Link: https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5637976466
Link: https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5645652752
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/6005
Assisted-by: Codex:GPT-6
Cc: André Eikmeyer <dev@deq.rocks>
Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
Co-developed-by: Ed Schofield <ed@aicharmers.com>
Signed-off-by: Ed Schofield <ed@aicharmers.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
 .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 54 +++++++++++++++++++
 1 file changed, 54 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 2d05088619f6d..672d740e72883 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -60,6 +60,25 @@
 
 static int navi10_init_ppt_limits(struct smu_context *smu);
 
+static bool is_asic_secure(struct smu_context *smu);
+
+static bool navi10_apple_needs_late_uclk(struct smu_context *smu)
+{
+	struct amdgpu_device *adev = smu->adev;
+	struct pci_dev *pdev = adev->pdev;
+
+	if (!(adev->pm.pp_feature & PP_MCLK_DPM_MASK))
+		return false;
+
+	/* Preserve the existing secure Navi 10 memory-DPM exclusion. */
+	if (is_asic_secure(smu) &&
+	    amdgpu_ip_version(adev, MP1_HWIP, 0) == IP_VERSION(11, 0, 0) &&
+	    adev->rev_id == 0)
+		return false;
+
+	return pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE;
+}
+
 static const struct smu_feature_bits navi10_dpm_features = {
 	.bits = {
 		SMU_FEATURE_BIT_INIT(FEATURE_DPM_PREFETCHER_BIT),
@@ -356,6 +375,11 @@ navi10_init_allowed_features(struct smu_context *smu)
 		smu_feature_list_set_bit(smu, SMU_FEATURE_LIST_ALLOWED, FEATURE_MEM_MVDD_SCALING_BIT);
 	}
 
+	/* Defer UCLK on the selected Apple boards until IP late init. */
+	if (navi10_apple_needs_late_uclk(smu))
+		smu_feature_list_clear_bit(smu, SMU_FEATURE_LIST_ALLOWED,
+					   FEATURE_DPM_UCLK_BIT);
+
 	if (is_asic_secure(smu) &&
 	    (amdgpu_ip_version(adev, MP1_HWIP, 0) == IP_VERSION(11, 0, 0)) &&
 	    (adev->rev_id == 0))
@@ -3219,6 +3243,30 @@ static int navi10_enable_mgpu_fan_boost(struct smu_context *smu)
 					       NULL);
 }
 
+/* IP late init follows display hw_init; refresh clocks before UMC/UMD setup. */
+static int navi10_apple_late_uclk_enable(struct smu_context *smu)
+{
+	struct smu_feature_bits enabled;
+	int ret;
+
+	if (!navi10_apple_needs_late_uclk(smu))
+		return 0;
+
+	ret = smu_cmn_feature_set_enabled(smu, SMU_FEATURE_DPM_UCLK_BIT, true);
+	if (ret)
+		return ret;
+	ret = smu_cmn_get_enabled_mask(smu, &enabled);
+	if (ret)
+		return ret;
+	if (!smu_feature_bits_is_set(&enabled, FEATURE_DPM_UCLK_BIT))
+		return -EIO;
+
+	smu_feature_list_set_bit(smu, SMU_FEATURE_LIST_SUPPORTED,
+				 FEATURE_DPM_UCLK_BIT);
+
+	return 0;
+}
+
 static int navi10_post_smu_init(struct smu_context *smu)
 {
 	struct amdgpu_device *adev = smu->adev;
@@ -3227,6 +3275,12 @@ static int navi10_post_smu_init(struct smu_context *smu)
 	if (amdgpu_sriov_vf(adev))
 		return 0;
 
+	ret = navi10_apple_late_uclk_enable(smu);
+	if (ret) {
+		dev_err(adev->dev, "Failed to enable late UCLK DPM: %d\n", ret);
+		return ret;
+	}
+
 	ret = navi10_run_umc_cdr_workaround(smu);
 	if (ret)
 		dev_err(adev->dev, "Failed to apply umc cdr workaround!\n");
-- 
2.56.0

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[André Eikmeyer]

On Tue, 3 Nov 2026 10:14:12 -0500
Alex Deucher <alexdeucher@gmail.com> wrote:

> I asked around internally with the windows team about this issue and
> was told macs needed to enable UCLK DPM later, but no one was aware of
> any uclk dpm patching.
Can you please elaborate about the relation between the windows team
and Apple logicboards? The macOS kexts even set a 740mhz cap for
particular memory chip revisions.

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Aditya Garg]

Hi Alex
> On Tue, Nov 3, 2026 at 10:01 AM Atharva Tiwari
> <atharvatiwarilinuxdev@gmail.com> wrote:
>>
>>> It is the same issue.  I don't want two fixes for the same issue. I
>>> just sent an updated version of this patch expanded to cover more
>>> macs.
>>>
>>> Alex
>>
>> How is the problems same exactly?, Does initializing UCLK later change the
>> PPTable?, and as said this is not even a solution for iMacs, so why are we
>> still trying to upstream this?, and btw initializing UCLK later with 5K,
>> makes it not initialize at all, so the patch is just wrong.
> 
> I asked around internally with the windows team about this issue and
> was told macs needed to enable UCLK DPM later, but no one was aware of
> any uclk dpm patching.We have filed multiple bug reports regarding the 5K issue on iMacs but they have simply been tagged and left over for many years. Now suddenly one day a person without properly consulting the author sends a patch upstream, inspite of the author himself saying doesn't work.

I own a MacBookPro16,1 and the v5 send doesn't work at all to fix it for me.

Since Windows team is willing to help us please fix the 5K issue on iMacs as well. And the devs aim achieve hybrid graphics, which Windows does not support.

For my testing results, the patch in v5 (https://lore.kernel.org/all/20261103143014.522592-1-alexander.deucher@amd.com/T/#u) doesn't solve what is claims to. It might be possible its needed, but in that case even more workups and patches should also needed to get the GPUs running properly on Linux only.

I believe patches submitted by the author himself should be acknowledged. We already are victims of AI cannon, pls don't make things worse.

Nacked-by: Aditya Garg <aditya.garg@linux.dev>

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[Atharva Tiwari]

> I forgot to remove the pptable check.  Can you try a simplified
> version of the patch?  I think all you need to do is delay the UCLK
> DPM enablement until late_init.  Something like the attached patch.
> 
> Alex

Also, i've tested this patch with the 5K patch, the UCLK then just never
gets initialized, so this patch is literally incompatible with 5K.

And also if ur wondering, what patch am i talking about you can see it here:
https://github.com/t2linux/linux-t2-patches/blob/main/7003-amdgpu-add-support-for-5K.patch

I still need to make combine patch (otherwise bad tearing in gnome/mutter), and i need to
enable 5K in EFI aswell to remove the shitty quirk to initialize display eariler than smu,
And make it usable with simpledrm.

Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs

[André Eikmeyer]

On Tue, 3 Nov 2026 10:53:56 -0500
Alex Deucher <alexdeucher@gmail.com> wrote:

> I forgot to remove the pptable check.  Can you try a simplified
> version of the patch?  I think all you need to do is delay the UCLK
> DPM enablement until late_init.  Something like the attached patch.
Alex, as I told you earlier.  I don't own a 16,1. I developed the patch
I submitted. It took me months to figure out while debugging via ssh.
Currently a community of nearly 6000 people are happily using it.
I dont understand your fixation towards a patch that fixes nothing. I
dont understand why you write patches based on obvious slop without even
being able to test. And I dont see why I should help you with it. There
is simply no point in it.