Shut the display down before handing over to the OS

[C-Prime90]

Firmware leaves the display controller and PHY running so the boot logo
survives handover. The next driver inherits live hardware and reprograms only
what it thinks changed, keeping firmware's settings — and the sink goes dark.

Disable the connectors and power the HDMI PHY down at ExitBootServices, so
whatever comes next brings the display up from scratch.

Only where the OS programs the display itself. Windows and ACPI-only Linux
scan out the GOP framebuffer, and for them the teardown is the failure, so
it's gated on a device tree plus LINUX_EFI_MEMRESERVE_TABLE_GUID — installed
by Linux's EFI stub just before ExitBootServices and by nothing else.

A Reset Display Before Boot option (default enabled) covers what detection
misses, such as a device-tree OS chainloaded without the stub. Also fixes
Reset to Defaults, which read DisplayModePresetDefault.Preset while the
driver published under another name, so it reset to 640x480.

Tested on a PowerStation 6 with Linux and Windows 11.

The HDMI Unprepare implementation isn't separable — upstream's is a // Todo
stub, so without it the teardown disables the controller but leaves the PHY at
firmware's settings and Linux loses video.

[mariobalanica]

I haven't looked too deep yet but it appears there have been recent changes to address this very issue (https://github.com/torvalds/linux/commits/master/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c). I didn't notice any hand-off issues a year ago, so it could very well be a regression.

Firmware isn't expected to power down the display path, but if kernels with this issue are already widely adopted by distros then I guess we do need a work around. But I would rather see whether it's possible to accomplish the clock reset via some FDT patches.

We also have a better way to do OS detection: https://github.com/edk2-porting/edk2-rk3588/blob/master/edk2-rockchip/Silicon/Rockchip/Drivers/RuntimeServicesManagerDxe/RuntimeServicesManagerDxe.c#L62, so the setup option is unnecessary.

[C-Prime90]

Could well be a regression — 7.1 and 7.2 still reproduce it, so whatever
landed in hdptx doesn't cover this case. Still live rather than already
fixed upstream.

It shows up with Display Mode at Native, which is the shipped default
(PcdDisplayModePresetDefault is DISPLAY_MODE_NATIVE): firmware hands over
a mode the kernel keeps, and the sink goes dark. So it's the out-of-box path.

Haven't tried the FDT route. If a reset property gets the kernel to reprogram
the PHY from scratch, that's the better fix and this can go.

Happy to drop the setup option and use the RuntimeServicesManagerDxe
detection instead.

[mariobalanica]

Is the GrfWrite in HdptxPowerDown actually needed, or do the PMU1CRU resets suffice? In that case it might be possible to abuse register-bit-led...but that's ugly and I'm not sure it buys us anything. Or we could also try assigned-clocks/assigned-clock-rates inside either the VOP or HDMI nodes, setting the HDMI PHY PLL clocks produced by phy-rockchip-samsung-hdptx to 0?

E.g.

&vop {
	assigned-clocks = <&hdptxphy0>, <&hdptxphy1>;
	assigned-clock-rates = <0>, <0>;
};

EDIT: 0 is likely not going to work, but the idea is assigning these clocks to a (still valid) value that's different from the firmware.