[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 #32 from Imre Deak <imre.deak at intel.com> ---
(In reply to Takashi Iwai from comment #30)
> (In reply to Imre Deak from comment #28)
> > (In reply to Takashi Iwai from comment #26)
> > >[...]
> > > > > 
> > > > > 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.

Well, it didn't really work in a generic way for anybody who wanted HDMI
functionality as we see now. But I'm not saying we should break the reporter's
machine, just trying to figure out what caused the problem and how could it be
solved in a way that also provides a more robust HDMI functionality.

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

So the i915 driver must (or should) be configured too for this user (b/c of
Kconfig dependency). So why the i915 driver didn't bind, is it because of
nomodeset/i915.modeset=0? In this case I think we could do a null-op binding
from the i915 side so you could bail out skipping HDMI probing.

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

Ok, so would the above null-op binding help?

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

Would the above null-op binding help?

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