<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#c30">Comment # 30</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>(In reply to Imre Deak from <a href="show_bug.cgi?id=94566#c28">comment #28</a>) > (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. The point is that it just worked. > > 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? y v > > > 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. The disablement of i915 KMS is often user's choice of action, and then it is no error, per se. We can't handle it as a fatal error in the audio side as a justification to shut off everything, especially if that action worked in the previous kernels. > > nomodeset option, for example, should be possible to be handled gracefully. > > You can check if nomodeset was passed on the command line. i915.modeset=0 is another option. And, it can be passed implicitly via /etc/modprobe.d/*. > > 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. Yes, we can check that the Intel VGA is present. I wrote it in my early comment, too. But, then how do you know that i915 graphics driver will really kick off the component? The i915 driver might be disabled (nomodeset or whatever) or it might fail to initialize. Then the audio driver still waits forever? > > > 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. nomodeset is just one case. There are others the audio driver can't know without help of graphics driver side. > > > > 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. Yes, and these are exceptions that should be handled as error, IMO. It's safer to have a timeout, really. You should never expect users doing sane :)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>