Timing issues between ALSA and i915 drivers

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

Hi,

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.

In other words, we are at a point where we either have DRM lockups or 
can't detect the HDMI audio codec, none of which are too good.

I don't have the background for the DRM lockup stuff, nor do I 
understand why snd_hdac_i915_init has to be called from a thread 
context. Is this really a requirement?

I also don't get what sort of timing issues would come from an 
initialization. What happens on the i915 side and is there some sort of 
mandatory delay between the completion of the i915_init and issuing a 
snd_hdac_chip_readw(bus, STATESTS) to get the codec masks on the HDaudio 
links?

Thanks for any pointers or comments.

-Pierre


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx