> -----Original Message----- > From: Takashi Iwai [mailto:tiwai@xxxxxxx] > Sent: Wednesday, March 16, 2016 10:03 PM > To: Yang, Libin > Cc: libin.yang@xxxxxxxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx; Lin, > Mengdong > Subject: Re: [PATCH] ALSA: hda - codec add DP MST support > for connection list > > On Wed, 16 Mar 2016 14:53:09 +0100, > Yang, Libin wrote: > > > > > > > From: Takashi Iwai [mailto:tiwai@xxxxxxx] > > > Sent: Wednesday, March 16, 2016 3:56 PM > > > To: Yang, Libin > > > Cc: libin.yang@xxxxxxxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx; Lin, > > > Mengdong > > > Subject: Re: [PATCH] ALSA: hda - codec add DP MST > support > > > for connection list > > > > > > On Wed, 16 Mar 2016 08:48:58 +0100, > > > Yang, Libin wrote: > > > > > > > > Hi Takashi, > > > > > > > > > -----Original Message----- > > > > > From: Takashi Iwai [mailto:tiwai@xxxxxxx] > > > > > Sent: Wednesday, March 16, 2016 3:35 PM > > > > > To: libin.yang@xxxxxxxxxxxxxxx > > > > > Cc: alsa-devel@xxxxxxxxxxxxxxxx; Yang, Libin; Lin, Mengdong > > > > > Subject: Re: [PATCH] ALSA: hda - codec add DP MST > > > support > > > > > for connection list > > > > > > > > > > On Wed, 16 Mar 2016 02:47:31 +0100, > > > > > libin.yang@xxxxxxxxxxxxxxx wrote: > > > > > > > > > > > > From: Libin Yang <libin.yang@xxxxxxxxxxxxxxx> > > > > > > > > > > > > This patches adds the support of connection list for DP MST. > > > > > > With this, hdmi driver in DP MST mode can easily reuse > > > > > > the connection list mechanism. > > > > > > > > > > > > Signed-off-by: Libin Yang <libin.yang@xxxxxxxxxxxxxxx> > > > > > > > > > > The merge window was already opened, so it's too late for this > kind of > > > > > change for 4.6, in anyway. > > > > > > > > That's OK. We can wait for later version. What do you think put this > > > patch > > > > and my later patches for MST in the topic branch, such as hdmi-jack > > > brach > > > > like before. Later patches for MST needs gfx driver support and our > > > > gfx driver is not ready for it. > > > > > > > > > > > > > > But, the fundamental question: why do we need to manage the > > > cached > > > > > list of the widget connection with a device index? In other words, > if > > > > > you have a different device index, does the widget connection > itself > > > > > also change? > > > > > > > > Based on my test, it should be the same. But from the spec, it says: > > > > > > > > 7.3.3.42 Device Select > > > > For Digital Display Pin Widget that is multi stream capable, the > Device > > > Select control determines which > > > > Device Entry is currently selected and accessible by the Pin Widget > verbs > > > which are controlling the sink > > > > device operations. This control verb is only required if it is a Digital > > > Display Pin Widget and multi stream > > > > capable. > > > > The index is in relation to the Device List associated with the widget. > The > > > index is a zero-based offset > > > > into the Device List. Once the Device Entry is selected by the Set > index, > > > all subsequent Pin Widget verbs > > > > controlling the sink device operations will be directed to the selected > > > Device Entry, until the Device Select > > > > verb get updated with a new value. These Pin Widget verbs include: > > > > Connection Select > > > > Get Connection List Entry > > > > Amplifier Gain/Mute > > > > Power State > > > > Pin Widget Control > > > > ELD Data > > > > DIP-Size > > > > DIP-Index > > > > DIP-Data > > > > DIP-XmitCtrl > > > > Content Protection Control > > > > ASP Channel Mapping > > > > > > > > So my understand is this may be changed. > > > > > > But the pin widget is the terminal. So, if you have a device index to > > > choose a device there, the widget connection list itself doesn't > > > change. Or am I missing anything? > > > > The pin may connect to several converters (for example), and it > > can choose which converter to use. And from the spec, it seems > > each device entry can have different connection list entry. > > However from my test, all device entries on the same pin will have > > the same list. > > Hrm, OK, so it makes sense to keep the list. OTOH, it means that the > connection list may change endlessly depending on the device index. > And, we likely need to clean up the connection list at unplug. I'm not sure whether the connection list will be changed when unplug. Suppose it should be the capability and will not change? > > (And also we may need to consider the protect against the concurrent > accesses...) Yes, we should protect it. Regards, Libin > > > thanks, > > Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
