[Bug 94566] [BAT SKL]igt at kms_pipe_crc_basic@suspend-read-crc-pipe-c fails suspend autoresume

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94566

--- Comment #13 from Imre Deak <imre.deak at intel.com> ---
(In reply to Takashi Iwai from comment #12)
> Aha, that's interesting.  Now it gets clearer.
> 
> My wild guess is like below:
> 
> - The system boots with both i915 and HDA as modules, and they are loaded /
> initialized asynchronously.
> 
> - i915 init takes some time, while HD-audio starts initializing the bus at
> first.
>   This results in the failure of the i915 component binding:
> 
> [    6.708025] snd_hda_intel 0000:00:1f.3: failed to add i915 component
> master (-19)
> 
> - Then i915 gets initialized, and HD-audio bus loads the HDMI codec driver.
>   The recent HDMI codec driver tries to bind with i915 by itself.  It was
> for the old chipset without Powerwell.  At this time, the binding succeeds:
> 
> [    8.857780] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops
> i915_audio_component_bind_ops [i915])
> 
> - Then the whole probe procedure finishes, it decreases the refcount, as if
> the bus had also bound with i915.  So it gets unbalanced.
> 
> 
> So, for the unbalanced PM refcount itself, we can avoid it by disabling the
> second on-demand binding.  But it means nothing but the i915 / HDA binding
> fails totally.

There is no guarantee which module gets loaded first and so no guarantee that
you won't get the "failed to add i915 component master (-19)" error. The only
proper way to solve this is to initialize anything needing the display driver
from the component bind hook (hdac_component_master_bind).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160318/30fb479d/attachment-0001.html>