I could use some feedback on HDMI audio issues exposed during the 4.21 merge window. By accident (misleading documentation) we ended up enabling the Skylake driver instead of the HDaudio legacy, and broke audio on a number of Skylake and ApolloLake devices where the HDMI/iDISP codec was not detected (bit 2 not set in the codec_mask). Linus' Dell XPS13 9350 was the first to be impacted of course...
After debugging a bit, this issue can be resolved by either
a) compiling both SOUND and DRM as built-ins (y instead of m)
b) moving the calls snd_hdac_i915_init() to the probe function instead of the worker queue (code at https://github.com/plbossart/sound/commits/fix/skl-hdmi)
Both solutions point to timing issues.
During internal reviews I was alerted to the fact that the suggested fix essentially reverts patch ab1b732d53c18 ('ASoC: Intel: Skylake: Move i915 registration to worker thread') which was introduced to solve DRM lockup issues.
I tried to narrow down the issue further and my current understanding is that the Skylake driver performs link reset operations without the display power turned on - which does not look like a very smart thing to do in hindsight.
In other words, it's not really when snd_hdac_i915_init() is called that matters as I assumed initially, but more when snd_hdac_display_power() is invoked. There are two cases where this happens, and for each of them turning the display power on results in HDMI detection. The attached diffs split the initialization from the power on, which provides a better understanding of the issue.
What would be really useful at this point is a confirmation that snd_hdac_i915_init() cannot be called in the initial probe but does need to be executed in a work queue. That would really impact the way the initialization sequence is reworked on the Skylake side as well as modify the way the SOF driver deals with i915 initialization.
Thanks
-Pierre