On Thu, 17 Jan 2019 21:47:05 +0100,
Pierre-Louis Bossart wrote:
>
>
> >> 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
>
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
On Thu, 17 Jan 2019 20:53:06 +0100,
Pierre-Louis Bossart wrote:
>
>
> > 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
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
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)
I added DRM+audio dmesg logs at the following link for reference:
