[alsa-devel] DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi,


> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Friday, October 16, 2015 5:01 PM
> To: Yang, Libin
> Cc: Raymond Yau; ALSA Development Mailing List; airlied at linux.ie; Lin,
> Mengdong; Girdwood, Liam R; tanuk at iki.fi; David Henningsson
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> On Fri, 16 Oct 2015 10:51:30 +0200,
> Yang, Libin wrote:
> >
> > Hi Takashi,
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai at suse.de]
> > > Sent: Friday, October 16, 2015 2:38 PM
> > > To: Raymond Yau
> > > Cc: Yang, Libin; ALSA Development Mailing List; airlied at linux.ie; Lin,
> > > Mengdong; Girdwood, Liam R; tanuk at iki.fi; David Henningsson
> > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > >
> > > On Fri, 16 Oct 2015 02:32:50 +0200,
> > > Raymond Yau wrote:
> > > >
> > > > > >
> > > > > > Do it mean that only one DP MST port and no HDMI port on
> the
> > > same
> > > > graphic
> > > > > > card ?
> > > > >
> > > > > No.
> > > >
> > > > If there is only one HDMI and one Display Port, this mean that
> there
> > > are
> > > > two pin complexes
> > >
> > > Yes, and the mapping doesn't change in this case as before.
> > >
> > > > How about the name of jack detection kctl of three Display Port
> > > monitors
> > > > which are created on the same pin complex but different
> dev_index ?
> > >
> > > It's one of the models we've considered.  Basically the number of
> > > devices can be up to 64 (or such) per pin.  For Intel case, due to the
> > > limitation of converters, it's up to 3.  For other GPUs that may drive
> > > more simultaneous outputs, the number increases in square.  If a
> GPU
> > > may handle 16 outputs, it'll be 256 entries.
> > >
> > > Although the 256 entries are certainly manageable as kctl, whether
> > > this is the best representation for user-space is a question.
> >
> > This is what I concern. Each device entry should have one tag
> > for unsol event. This means each device entry will create a jack?
> 
> Yes, and essentially each entry corresponds to a PCM, so we'll end up
> with 256 PCM (sub)streams :)  This doesn't scale.
> 
> So, thinking of this issue again, I'm convinced now that static PCM
> entries with extra dynamic PCM slots as David suggested would work
> more safely.  The number of dynamic PCMs can be either a fixed
> number
> per driver type, a constant, or variable via module option.

Yes, we will use static PCM allocation and dynamic PCM attachment. :)

For the Jack, I think I need do some investigation on the HW
whether I can use dynamic attachment or not.

> 
> 
> Takashi