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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Mar 19 10:49:04 UTC 2016


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

--- Comment #31 from Takashi Iwai <tiwai at suse.de> ---
(In reply to Imre Deak from comment #29)
> (In reply to Takashi Iwai from comment #25)
> > (In reply to Imre Deak from comment #24)
> > > (In reply to Takashi Iwai from comment #22)
> > > > (In reply to Imre Deak from comment #20)
> > > > > (In reply to Takashi Iwai from comment #17)
> > > > > > And, one more problem is that we gather up the all codecs as a single card. 
> > > > > > Blocking a probe of one codec means to block the probe of the whole card. 
> > > > > > So we can't take unlimited block behavior.
> > > > > 
> > > > > Can you still separate interface registration from HW access? I assume the
> > > > > latter could be delay until the user first opens the device node, so you
> > > > > could do the blocking there and register the corresponding interface earlier.
> > > > 
> > > > It's difficult, unfortunately.  HDMI codec may provide multiple streams (or
> > > > even zero stream), and for knowing how many streams, we need to probe.  So,
> > > > without probing, we don't know which device interface to provide.
> > > >  
> > > > And, on SKL architecture, the HDMI codec is on the same HDA bus that is
> > > > represented as a single sound card instance. 
> > > 
> > > Why can't the HDMI codec be on a separate sound card?
> > 
> > Because currently we build the card per PCI controller, as the PCI
> > controller governs the stream DMA.
> 
> Ok, but is it in practice possible? Sound card looks like a software
> abstraction to me, behind which you could implement your own way of
> arbitrating access to the HW among the separate sound cards.

Possible, but really tough.

Imagine to split i915 driver to multiple individual drm drivers, each of which
takes care of only one output (VGA, eDP, HDMI, DP).  Your suggestion is
something like that.

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


More information about the intel-gfx-bugs mailing list