[alsa-devel] [RFC PATCH 0/3] support DP MST audio

[Takashi Iwai]

On Wed, 28 Sep 2016 04:50:53 +0200,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> > > > If so, now my question again: for devid!=0, which connections are
> > > > given statically?  In other words, how many devid would be passed?
> > >
> > > For the connection list, it is static. It will be initialized at bootup.
> > 
> > So this is only about devid=0, right?  For devid!=0, there wouldn't be anything
> > else than pin/cvt connections, correct?
> 
> Devid != 0 is the same as devid = 0. And there is only pin/cvt connections.
> 
> My basic idea is:
> 1. Every device entry use a virtual pin

OK.

> 2. Each device entry will be initialized at bootup even it is not in MST mode.

Here starts unclearness.  How "*each* device entry" will be enumerated
at boot up time?  The device id can be arbitrary numbers, per spec.

And "even it is not in MST" means the devices that aren't capable MST
(like SandyBridge HDMI/DP)?  Or it's meant "even when no monitor is
connected via MST"?

>     This means after bootup, mode change will not add/remove the per_pin.

What here "mode" means exactly?

> 3. All device entries under the same pin will use the same connection list.
>     And the connection list is initialized at bootup. It will be saved in
>     per_pin->mux_nids. This will never be changed after bootup.
>     (However the pin-cvt connection is dynamically assigned when necessary.)
> 
> > 
> > > For the pin and cvt actual connection, it is dynamically assigned.
> > 
> > ... but you still want to cache this to an (ever-growing) array for the standard
> > connection lists.  That's what I was concerned.
> 
> Do you mean codec->conn_list? If we don't use the dev_id and all
> the device entries under the same pin use the same one, it will be
> exactly the same as before.

But you touch the whole codes doing the connection list caching even
by adding the dev_id field.  Why this is needed if you don't use the
dev_id...?

Again, try not to mess up the core code as a start.  The virtual pin
concept is OK as long as it's self-contained in the HDMI codec
driver.  And adding some basic calls to handle the device id is fine.
But the way to change as in patch 1 can't be included without the
enough justification.


thanks,

Takashi