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

[Yang, Libin]

Hi Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Wednesday, September 28, 2016 3:57 PM
> To: Yang, Libin <libin.yang at intel.com>
> Cc: libin.yang at linux.intel.com; alsa-devel at alsa-project.org; Lin, Mengdong
> <mengdong.lin at intel.com>
> Subject: Re: [alsa-devel] [RFC PATCH 0/3] support DP MST audio
> 
> 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.

This is a good question. We really met such issue. We currently is to judge
whether it is support MST or not (if it is haswell_plus, then it supports MST).
We didn't use snd_hda_get_num_devices() to get the device number.

And if it is MST, then everything works well, each per_pin represents a device
entry.

If it is NON-MST, the device id means nothing, and snd_hda_set_dev_select()
does nothing. So we will use the first device entry (dev_id = 0) to represent
the pin.

> 
> 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"?

I mean " even when no monitor is connected via MST". Actually, when
initialization, driver will judge the platform supports MST or not (for intel,
only haswell_plus support MST).

> 
> >     This means after bootup, mode change will not add/remove the per_pin.
> 
> What here "mode" means exactly?

Mode means MST mode or NON_MST mode.

> 
> > 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.

Yes, I understand and I will refine the patch and not touch the 
connection list core code in next patchset. In the new patch, dev_id 
will not be used in connection list. I will totally remove the patch 1.

Regards,
Libin

> 
> 
> thanks,
> 
> Takashi