[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 #29 from Imre Deak <imre.deak at intel.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact 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/709e3fea/attachment.html>