<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#c28">Comment # 28</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#c26">comment #26</a>) >[...] > > > > > > Yes, but it shouldn't fail for the Realtek audio codec, but should fail > > > (drop) only HDMI codec. > > > > Assuming the limitation that the HDMI codec cannot be registered > > dynamically, the Realtek codec probing should also fail in this case. Yes, > > it sucks, but that's inherent in the audio framework and not a problem of > > the HDA driver. > > Sorry, this no-go. To support this you need to fix the audio framework to allow for dynamic registration of the HDMI codec. > It's a clear regression from the previous kernels, and I > know people expecting this works like that. (I've got bug reports in the > past for similar things already.) Could you describe the exact configuration? Is Intel HDMI support enabled in Kconfig? Is there an Intel HDMI codec present in the bug reporter's system? > > In any case this can only arise due to a kernel > > configuration problem, or in case of an error as discussed earlier, so in > > both cases it's not too unexpected to lose audio. > > It's not always an "error". Please specify in which case, I would like to better understand. > nomodeset option, for example, should be possible to be handled gracefully. You can check if nomodeset was passed on the command line. > The missing i915 module can be seen as a configuration error, and we have > some excuse not to make things working well. But nomodeset is just a > runtime configuration, and it shouldn't affect the things that worked in > previous kernels. > > > > Here comes back to the question again: for knowing what codec is on the bus, > > > we already need i915 binding. > > > > To know that there is an Intel HDMI codec on the bus, you don't need the > > binding you can just look at PCIIDs. > > No, on SKL or BSW, there is no PCI controller for HDMI. So why not check for the presence of SKL, BSW etc. graphics PCIIDs? That does indicate the presence of an HDMI codec. > > At this point you know you'll have to > > delay the probing of the HDMI codec (or any other codec due to the audio > > framework limitation) until the component binding completes. > > > > > But how to fail i915 binding in this case? > > > > You don't need to fail it, whenever the audio driver decides to wait for the > > binding to complete (based on PCIIDs and Intel HDMI support being enabled in > > the audio Kconfig) the i915 driver must be present (because of a Kconfig > > dependency) and loaded eventually. The only cases when binding wouldn't > > complete are exceptional, the nomodeset and error cases discussed earlier. > > The question is how to decide to wait or not. > For nomodeset case, clearly we shouldn't wait. The audio driver can check if nomodeset was passed. > > > Will i915 driver inform to component? > > > > In which case? The only reason i915 wouldn't initiate the binding is some > > error case, when it's also ok to fail audio probing (provided the audio > > driver decided to wait based on the previous point). > > Well, my question is how the audio driver knows that i915 failed to register > the slave. Otherwise the audio driver will wait forever with a hope i915 > will register anytime later. > > > > What if the module isn't present (e.g. in the limited initrd)? > > > > And it's in the rootfs only? Then it's ok to wait with audio probing until > > the i915 module gets loaded from the rootfs. > > The question is how long we may block. I guess some blocking behavior with > timeout is acceptable for this particular case, as it's a system > configuration problem. But again, nomodeset is a different matter. I don't think we need some timeout, it's an exceptional case if binding doesn't complete in a timely manner.</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>