<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#c23">Comment # 23</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#c21">comment #21</a>) > (In reply to Imre Deak from <a href="show_bug.cgi?id=94566#c18">comment #18</a>) > > (In reply to Takashi Iwai from <a href="show_bug.cgi?id=94566#c16">comment #16</a>) > > > Well, this is a sort of chicken-and-egg problem. For probing the HDMI > > > codec, i915 binding is needed, yes. But, for knowing whether it's a HDMI > > > codec or not, we need to probe the codec at first. Thus the driver needs > > > the i915 binding *before* probing the codec. Yet, i915 binding can't be > > > done when the system has no i915 graphics... > > > > I don't think it's a chicken-and-egg problem. There are two possibilities: > > > > 1. Probing the codec needs a power well provided by the i915 device and as > > such the i915 driver. In this case there must be an i915 graphics device > > physically present in the system and so you can load the i915 driver which > > will end up doing the binding. You said that it's not clear yet whether this > > HW dependency really exists, I have no idea either, so someone needs to find > > the definite answer for this. > > This is the case we're assuming, so far. And, here we have a dependency > problem. > > > 2. Probing the codec doesn't need an i915 provided power well (or any other > > functionality provided via the component interface), in which case there is > > no problem you just need to remove the power_well get/puts and probe the > > codec whenever. > > A remaining question in this case is how to bail out when no graphics driver > is available even if the graphics hardware is on the machine. In the > current binding mechanism, it'll wait forever? 1. If you mean no graphics driver because it wasn't enabled in Kconfig: that is an invalid configuration you shouldn't allow if Intel HDMI support in the audio driver is enabled in Kconfig; you need a Kconfig dependency for this. 2. If you mean the user boots with nomodeset or the i915 driver fails to probe: in the former case the user should know that audio will also stop working. In both cases it's to be expected that audio won't be available. Other than the above scenarios I don't see why the binding wouldn't complete eventually. > > > We may look for Intel VGA PCI entries, and enable i915 binding only when > > > found. This would work in most cases, but not in 100%. User may still > > > build / use a system without graphics (e.g. booting with nomodeset option). > > > > In case 1. above booting with modeset or otherwise not having the i915 > > driver for some reason would also imply a lack of audio support, that is you > > would need to fail the probing of the audio driver. > > 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. 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. > 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. 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. > 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). > 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.</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 assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>