[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 #21 from Takashi Iwai <tiwai at suse.de> ---
(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?

> > 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.  Here comes back to the question again: for knowing what codec
is on the bus, we already need i915 binding.  But how to fail i915 binding in
this case?  Will i915 driver inform to component?  What if the module isn't
present (e.g. in the limited initrd)?

-- 
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/1786407b/attachment.html>