mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ed Schofield <ed@charmerstraining.com>
To: alexdeucher@gmail.com
Cc: atharvatiwarilinuxdev@gmail.com, dev@deq.rocks,
	aditya.garg@linux.dev, alexander.deucher@amd.com,
	kenneth.feng@amd.com, christian.koenig@amd.com,
	airlied@gmail.com, simona@ffwll.ch,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] drm/amd/pm: defer UCLK DPM on selected Apple Navi GPUs
Date: Wed,  4 Nov 2026 23:52:41 +1100	[thread overview]
Message-ID: <20261104125241.39209-1-ed@charmerstraining.com> (raw)
In-Reply-To: <CADnq5_N-sobVK3qitqABjqMv2HMyGNdxX0XMXa4TZzVnMv8MLA@mail.gmail.com>

Hi Alex, hi Atharva, hi all,

Alex, I'd like to withdraw my September v4 submission. I also don't support
applying v5 as posted or the simplified patch you attached later in this
thread. Please remove my Co-developed-by and Signed-off-by tags from both
versions. I no longer think deferring UCLK is the right approach for the iMacs.

I also excluded the MacBookPro16,1 (020f) from v4 deliberately because a tester
found that with deferred UCLK it still hung after login, as it does without the
patch [1], which seems to fit André's PPTable diagnosis.

Since then, I've been working with Atharva to get his native-5K iMac support
upstream. His patch initializes the display before the SMU, which has also
prevented the boot failures without deferring UCLK. On my iMac20,1 (0218), 13
of 20 warm boots failed with the upstream order; with display first, all 40
boots passed [4]. Another tester reported one warm and one cold boot, both
successful, on a 0219 [2]. On an iMac20,2 (021a), changing only the
initialization order improved warm boot success from 11 out of 20 to 100 out of
100 [3]. His patch only applies to the iMac20,1 and iMac20,2, so it doesn't fix
the 16,1 either.

I don't think the iMacs and the MacBookPro16,1 have the same problem. The
iMacs fail while amdgpu is loading: the SMU stops responding to
EnableAllSmuFeatures (message 6), and the probe fails with -62. With the
display initialized first, the same message succeeds with UCLK included,
and the iMac boots normally. The 16,1 loads amdgpu without errors and hangs
later, after login, with or without deferred UCLK [1]. So deferring UCLK
seems to help the iMacs only because it moves the enable after display
init, and it doesn't help the MacBookPro16,1.

I have prepared a draft patch with Atharva as author and me as co-developer,
incorporating his review feedback. It combines display-first initialization and
native 5120x2880 support through two tiled connectors with suspend/resume and
display power-management changes. The current draft is here:

https://github.com/edschofield/linux-t2-patches/blob/7273823e425200e9f371e9272e02ebf9abb6f1c2/7003-amdgpu-add-support-for-5K.patch

This has passed some initial automated testing on my iMac20,1 but I need to do
more testing and get Atharva's final review and sign-off.

Alex, thanks for following up on the boot issue and checking with the Windows
team.

Best regards,
Ed

[1] https://github.com/t2linux/linux-t2-patches/pull/61#issuecomment-5646139127
[2] https://github.com/t2linux/wiki/issues/743#issuecomment-6083265811
[3] https://github.com/t2linux/wiki/issues/743#issuecomment-6131809640
[4] https://github.com/t2linux/wiki/issues/743#issuecomment-6163146905

  parent reply	other threads:[~2026-11-04 12:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 14:40 Ed Schofield
2026-10-29 21:57 ` Alex Deucher
2026-10-30  1:55   ` Atharva Tiwari
2026-10-30 11:30   ` André Eikmeyer
2026-11-03 14:30     ` Alex Deucher
2026-11-03 15:00       ` Atharva Tiwari
2026-11-03 15:14         ` Alex Deucher
2026-11-03 15:59           ` André Eikmeyer
2026-11-03 16:00           ` Aditya Garg
2026-11-04 12:52           ` Ed Schofield [this message]
2026-11-04 14:07             ` Alex Deucher
2026-11-04 14:20               ` Aditya Garg
2026-11-03 15:25       ` André Eikmeyer
2026-11-03 15:53         ` Alex Deucher
2026-11-03 16:05           ` Atharva Tiwari
2026-11-03 16:15           ` André Eikmeyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261104125241.39209-1-ed@charmerstraining.com \
    --to=ed@charmerstraining.com \
    --cc=aditya.garg@linux.dev \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=atharvatiwarilinuxdev@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dev@deq.rocks \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kenneth.feng@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®