<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [BAT SKL]igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c fails suspend autoresume" href="https://bugs.freedesktop.org/show_bug.cgi?id=94566#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [BAT SKL]igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c fails suspend autoresume" href="https://bugs.freedesktop.org/show_bug.cgi?id=94566">bug 94566</a> from <a class="email" href="mailto:tiwai@suse.de" title="Takashi Iwai <tiwai@suse.de>"> Takashi Iwai</a> <pre>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. I wonder how this worked in the past. Did the HDMI audio test pass even before reloading the modules?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>