<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#c15">Comment # 15</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:imre.deak@intel.com" title="Imre Deak <imre.deak@intel.com>"> Imre Deak</a> <pre>(In reply to Takashi Iwai from <a href="show_bug.cgi?id=94566#c14">comment #14</a>) > (In reply to Imre Deak from <a href="show_bug.cgi?id=94566#c13">comment #13</a>) > > 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). > > Yes, but the reason we didn't do this is because we heard that the i915 > powerwell has to be enabled *before* the codec gets probed. So, it's rather > surprising that the codec probe succeeded even without the powerwell hook. > Maybe it just worked because they were probed in parallel. Or, the > information from Intel hardware team might be wrong. Who knows. That would mean that the very first time you can physically probe the codec is when i915 is already loaded and hence hdac_component_master_bind() gets called. There is just no way around this. > And, we can't block for syncing with i915 slave bind at the HD-audio bus > probe time, either. There are SKL systems without i915 graphics, and the > same HD-audio bus is used for the Realtek codec for builtin audio. So, the > missing i915 binding is no fatal error on such systems. Right, but then you have to split out the parts that have a hard dependency on the i915 driver, and initialize that part when the binding completes. There is again, just no way around this. > That said, the current non-blocking behavior is on purpose. But, *if* the > codec probe would work without the powerwell hook in the controller side > beforehand, we an put the blocking component binding again at the codec > probe. This might work -- but the technical information is missing whether > it's correct or not. I think you'd need to determine what parts of the HDA driver have a hard dependency on i915, split those out and init them from component bind hook. Everything else can get initialized earlier, for example the Skylake/Realtek stuff you mention above.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>