[Bug 94566] [BAT SKL]igt at kms_pipe_crc_basic@suspend-read-crc-pipe-c fails suspend autoresume

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94566

--- Comment #26 from Takashi Iwai <tiwai at suse.de> ---
(In reply to Imre Deak from comment #23)
> (In reply to Takashi Iwai from comment #21)
> > (In reply to Imre Deak from comment #18)
> > > (In reply to Takashi Iwai from comment #16)
> > > > 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.

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.)

> 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".  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.

> > 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.

>  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.

> > 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160319/e4dae5b5/attachment-0001.html>