<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><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#c26">Comment # 26</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 <span class="vcard"><a class="email" href="mailto:tiwai@suse.de" title="Takashi Iwai <tiwai@suse.de>"> <span class="fn">Takashi Iwai</span></a>
</span></b>
<pre>(In reply to Imre Deak from <a href="show_bug.cgi?id=94566#c23">comment #23</a>)
<span class="quote">> (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.</span >
Sorry, this no-go. 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.)
<span class="quote">> 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.</span >
It's not always an "error". nomodeset option, for example, should be possible
to be handled gracefully.
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.
<span class="quote">> > 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.</span >
No, on SKL or BSW, there is no PCI controller for HDMI.
<span class="quote">> 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.</span >
The question is how to decide to wait or not.
For nomodeset case, clearly we shouldn't wait.
<span class="quote">> > 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).</span >
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.
<span class="quote">> > 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.</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<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>