Re: [PATCH] drm/amd/amdgpu: Add 5K Support for iMac20,1 and iMac20,2

[Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>]

> That sounds like a separate logical change from the rest of the patch.
> If changing the order of the init sequence fixes the SMU UCLK issue,
> that should be a separate patch from the changes to enable the 5K
> display.  That said, I'm not really keen on this change.  Can you dig
> further and figure out what the actual issue is?  There are now 3
> separate slightly different fixes for this for people with various
> Macs:
> 1. Enabling UCLK DPM in late init
> 2. Using the UCLK states from the UMC DPM table
> 3. Changing the init order for specific Mac models

I can understand your confusion, so i have tested some scenario's to
make you understand the situation. And for the moment you can assume
that OCLP is a efi loader that sets 0x4f1 to 1.

1. Stock Amdgpu, Without OCLP (0x4f1 = 0): Crashes 6/10 times, 3840x2160, UCLK works
2. Stock Amdgpu, With OCLP (0x4f1 = 1): Crashes 0/10 times, 2560x2880 (1 tile streched), UCLK works
3. Late UCLK patch, Without OCLP (0x4f1 = 0): Crashes 0/10 times, 3840x2160, UCLK works
4. Late UCLK patch, With OCLP (0x4f1 = 1): Crashes 0/10 times, 2560x2880, UCLK does not work (Command are sent BUT no change in hardware).
5. This patch, Without OCLP, Without revised boot order
	 (0x4f1 = 0, at boot, after amdgpu init 0x4f1 = 1): Crashes 5/10 times, 5120x2880, UCLK works
6. This patch, With OCLP, Without revised boot order (0x4f1 = 1): Crashes 0/10 times, 5120x2880, UCLK works
7. This patch, without OCLP, With revised boot order
	(0x4f1 = 0, at boot, after amdgpu init 0x4f1 = 1): Crashes 0/10 times, 5120x2880, UCLK works
8. This patch, with OCLP, With revised boot order
	(0x4f1 = 1): Crashes 0/10 times, 5120x2880, UCLK works

So from these scenario's you can probably conclude that 0x4F1 = 1 is needed for SMU to boot properly
and thats the reason for the init order change, to set 0x4F1 before SMU init, if we can for example set
0x4F1 in EFI (x86-libstub) (like OCLP), we dont need the init order change, but to do that we need to RE the DXE
modules in apple EFI and check how apple's firmware sets 0x4f1 = 1.
And even OCLP does not enable 0x4F1 on its own, its fakes being macOS, and then the
DXE modules turn 0x4F1 on, for the "faking" macOS, we need EFI changes across iMacs which is not fesiable.

And the UMC DPM tables patch does not interfere with anything, its not needed for iMacs.