[DNM][WIP] HDA/SOF/i915: Do not create device link for HDMI audio whe…

[ujfalusi]

…n SOF is used

There seams to be no reason to create the device link between display and audio when it is used with SOF.

[kv2019i]

Dug up the old commit from Imre that added the link (2018, predates my time in Intel audio):
commit aef9f33

The commit message doesn't go into details w.r.t. the dependencies on audio side. We clearly have cases (like Haswell, discrete GPU cases) where the link is needed, but the needs for cases like SOF (where controller is on its own PCI device), are less well documented.

My primary concern is does this resurface bugs like: commit e3c714b (see lot of discussion around 2020 #1764) bugs like

• failed to get afg sub nodes on ChromeOS devices #1642
• [BUG] [TGL]HDMI/DP aplay failed and can not be released after wake up from s2idle  #1651
• [ICL][BUG]HDMI has no sound output after wake up from s3 during HDMI playback #1080
• HDMI probe fails to codec #2 probe error, ret: -5 #1375

I think most of these relate to setting the HDA bus parameters (T-mode and clock-pull settings). In large amount of devices, the hardware defaults are correct (= match the settings BIOS will set for audio side), but especially in TGL/ADL products, we had cases where this was not the case and we had HDA VERBs fail to the display code. Spec-wise this is not clearcut, and in theory shoudl work, but in practise we did get bug reports unless we used a strict order and ensured a get_power() call before HDA controller reset.

But, but, this PR does NOT remove the get_power() calls in SOF resume though, so in theory this should still work. I'm not 100% sure what happens when audio calls get_power() when i915 is not fulled resumed. Will the call block until display is powered up?

[ujfalusi]

replaced by: #5458