AMD General Oh ok, thanks a lot, Ed. Since it is Linux, I assume that Apple does not pay much attention to it. Once your patch is merged with Atharva's and tested, then we can review and get them checked in.
-----Original Message----- From: Ed Schofield <[email protected]> Sent: Wednesday, September 9, 2026 4:02 PM To: Feng, Kenneth <[email protected]> Cc: Atharva Tiwari <[email protected]>; Guna R . Bharati <[email protected]>; Deucher, Alexander <[email protected]>; Koenig, Christian <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [PATCH] drm/amdgpu/smu: Enable UCLK after init in AMD Radeon Pro 5300 Hi Kenneth, hi Atharva, Thanks for bringing the two threads together. I've tried your suggestion on my iMac20,1 (1002:7340 / 106b:0218, revision 0x41), with SMU firmware 53.38.0. I tried two warm boots and both failed. On the same AMD staging base as my RFC, I moved UCLK enablement to the beginning of navi10_set_default_dpm_table(), along with the readback check and supported-feature update. I removed the later enable and refresh from post-init. UCLK was still excluded from enable-all, and both memory-voltage features stayed the same. I didn't add any delay or extra mailbox tracing. Both boots reported: SMU: No response msg_reg: 8 resp_reg: 0 in params:00000008 Apple 0218 default-table UCLK enable failed: -62 AMDGPU failed to bind in both cases. I checked that the experimental module was loaded and the firmware files hadn't changed. This also fits an earlier test with T2 7.1.8. With UCLK excluded from enable-all, I tried enabling it separately immediately after smu_v11_0_system_features_control(smu, true) returned successfully. The trace shows EnableAllSmuFeatures returning 0x1, then EnableSmuFeaturesLow with argument 0x8 timing out with response 0 and -ETIME. The default-table function is reached only after enable-all returns successfully, so waiting for that acknowledgement doesn't seem to be enough on this board. I don't yet know whether it needs more time or some other initialization step. I'd keep post-init for now: that version passed the ten recorded AMD staging warm boots. These tests don't establish the earliest safe point. As for Apple, I can't speak for Apple or confirm their approval. I'm testing this as a Linux user. Do we need their input before merging an Apple-specific workaround? If so, could AMD help find the right contact? I'd still welcome a fix for the underlying firmware problem. I agree we should coordinate the two patches. Mine covers only 0218/rev 0x41; Atharva's covers 0219. We'd need to test the combined change on both boards before broadening the match. Thanks! Ed
