DP1.2 MST audio support discussion

DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi and all,

We are planning to enable DP1.2 MST (Multi-Stream Transport)
audio.

Based on the previous discussion, we will extend the 
struct hdmi_spec_per_pin to support MST audio device entry. 
So the struct hdmi_spec_per_pin can be a real pin or a device
entry in the pin.  The idea is to add a member dev_idx in the 
struct hdmi_spec_per_pin. Dev_idx, together with pin_nid,
can represent a device entry.

1. Dynamic PCM assignment
We will use dynamic PCM assignment for MST audio. This
means we will create a fixed number of PCMs (the number
is the same convertor number). All the created PCMs will not
be assigned to any pin (device entry). When there is a monitor
connected, an available PCM will be assigned to the pin. And
it will be de-assigned when the monitor is disconnected.
Userspace can fetch the HW param when monitor connection
status is changed.

I'm not sure how to notify the userspace, such as notifying
pulseaudio the PCM is assigned or de-assigned. Any ideas?

2. Compatibility.
We will patch patch_hdmi.c to support the MST audio.
Will we use mst audio driver to support the old mode
or we use a flag, when HW doesn't support MST audio,
we will use the old code? Suppose MST audio driver should
be able support both MST audio and non-MST audio.


Regards,
Libin

Re: DP1.2 MST audio support discussion

[David Henningsson]

Hi Libin,

On 2015-10-13 08:25, Yang, Libin wrote:
> Hi Takashi and all,
>
> We are planning to enable DP1.2 MST (Multi-Stream Transport)
> audio.

This was also discussed during the audio mini-summit in Dublin last week.

>
> Based on the previous discussion, we will extend the
> struct hdmi_spec_per_pin to support MST audio device entry.
> So the struct hdmi_spec_per_pin can be a real pin or a device
> entry in the pin.  The idea is to add a member dev_idx in the
> struct hdmi_spec_per_pin. Dev_idx, together with pin_nid,
> can represent a device entry.
>
> 1. Dynamic PCM assignment
> We will use dynamic PCM assignment for MST audio. This
> means we will create a fixed number of PCMs (the number
> is the same convertor number). All the created PCMs will not
> be assigned to any pin (device entry). When there is a monitor
> connected, an available PCM will be assigned to the pin. And
> it will be de-assigned when the monitor is disconnected.
> Userspace can fetch the HW param when monitor connection
> status is changed.

For the dynamic PCM assignment, the suggestion is to try to use static 
as much as possible. That is, first try the existing static mapping 
(port B -> 3, port C -> 7, port D -> 8), and only if that PCM is already 
being used, try another PCM.

One could then allocate two extra PCMs from the start (9 and 10) to try 
in case the other PCM is busy (my preference), or one could steal one of 
the existing non-busy ones (Takashi's preference).

> I'm not sure how to notify the userspace, such as notifying
> pulseaudio the PCM is assigned or de-assigned. Any ideas?

Userspace will receive change events on Jack and ELD kctls which can be 
used for this. However, there's not yet code in PulseAudio that will 
re-probe a PCM when a Jack event is received.

> 2. Compatibility.
> We will patch patch_hdmi.c to support the MST audio.
> Will we use mst audio driver to support the old mode
> or we use a flag, when HW doesn't support MST audio,
> we will use the old code? Suppose MST audio driver should
> be able support both MST audio and non-MST audio.

Apparently, the suggestion seems to be three hdmi codec drivers for the 
same hardware? One with MST audio, one without MST audio, and one ported 
to the ASoC framework :-/


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi David

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Tuesday, October 13, 2015 2:48 PM
> To: Yang, Libin; 'Takashi Iwai'; Lin, Mengdong; tanuk@iki.fi; Girdwood,
> Liam R
> Cc: alsa-devel@alsa-project.org; airlied@linux.ie
> Subject: Re: DP1.2 MST audio support discussion
> 
> Hi Libin,
> 
> On 2015-10-13 08:25, Yang, Libin wrote:
> > Hi Takashi and all,
> >
> > We are planning to enable DP1.2 MST (Multi-Stream Transport)
> > audio.
> 
> This was also discussed during the audio mini-summit in Dublin last
> week.

Yes, Mengdong has talked with me. And I will implement the DP1.2
MST audio based on the audio mini-summit discussion.

> 
> >
> > Based on the previous discussion, we will extend the
> > struct hdmi_spec_per_pin to support MST audio device entry.
> > So the struct hdmi_spec_per_pin can be a real pin or a device
> > entry in the pin.  The idea is to add a member dev_idx in the
> > struct hdmi_spec_per_pin. Dev_idx, together with pin_nid,
> > can represent a device entry.
> >
> > 1. Dynamic PCM assignment
> > We will use dynamic PCM assignment for MST audio. This
> > means we will create a fixed number of PCMs (the number
> > is the same convertor number). All the created PCMs will not
> > be assigned to any pin (device entry). When there is a monitor
> > connected, an available PCM will be assigned to the pin. And
> > it will be de-assigned when the monitor is disconnected.
> > Userspace can fetch the HW param when monitor connection
> > status is changed.
> 
> For the dynamic PCM assignment, the suggestion is to try to use static
> as much as possible. That is, first try the existing static mapping
> (port B -> 3, port C -> 7, port D -> 8), and only if that PCM is already
> being used, try another PCM.

Do you mean the each pin has its prefer PCM? It should be OK.

> 
> One could then allocate two extra PCMs from the start (9 and 10) to
> try
> in case the other PCM is busy (my preference), or one could steal one
> of
> the existing non-busy ones (Takashi's preference).

We will create the PCMs based on converter. This means we will
create 3 PCMs. And it will not support dynamically allocating PCM.
As there are only 3 converters, no more PCMs will be supported.
Each PCM will use one converter. If 3 PCMs are all used, connecting
monitor will not create new PCM.

Yes, if we are not using the PCM, we can re-assign the PCM to another
monitor. Currently, user can't decide which PCM is used for which
monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7 is 
assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
connected, no PCM is available, and driver don't know whether it
should steal one PCM for the monitor 4 and user can't change the
mapping currently.

Actually, before sending the email, I was thinking to export
an interface to userspace to let user select which PCM will be bound
to the monitor. But it is a little complex.

> 
> > I'm not sure how to notify the userspace, such as notifying
> > pulseaudio the PCM is assigned or de-assigned. Any ideas?
> 
> Userspace will receive change events on Jack and ELD kctls which can
> be
> used for this. However, there's not yet code in PulseAudio that will
> re-probe a PCM when a Jack event is received.

Do you mean to use the existed notifiers for PCM and no
new notifier is needed?

> 
> > 2. Compatibility.
> > We will patch patch_hdmi.c to support the MST audio.
> > Will we use mst audio driver to support the old mode
> > or we use a flag, when HW doesn't support MST audio,
> > we will use the old code? Suppose MST audio driver should
> > be able support both MST audio and non-MST audio.
> 
> Apparently, the suggestion seems to be three hdmi codec drivers for
> the
> same hardware? One with MST audio, one without MST audio, and
> one ported
> to the ASoC framework :-/

Not sure, I think we can use one hdmi codec driver for HD Audio, another
one for ASoC. It's based on the conclusion of the discussion.

Regards,
Libin

> 
> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Tue, 13 Oct 2015 09:34:49 +0200,
Yang, Libin wrote:
> 
> > One could then allocate two extra PCMs from the start (9 and 10) to
> > try
> > in case the other PCM is busy (my preference), or one could steal one
> > of
> > the existing non-busy ones (Takashi's preference).
> 
> We will create the PCMs based on converter. This means we will
> create 3 PCMs. And it will not support dynamically allocating PCM.
> As there are only 3 converters, no more PCMs will be supported.
> Each PCM will use one converter. If 3 PCMs are all used, connecting
> monitor will not create new PCM.
> 
> Yes, if we are not using the PCM, we can re-assign the PCM to another
> monitor. Currently, user can't decide which PCM is used for which
> monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7 is 
> assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
> connected, no PCM is available, and driver don't know whether it
> should steal one PCM for the monitor 4 and user can't change the
> mapping currently.

Actually, there are a few things to implement properly:

1. The plug/unplug events are triggered at the actual graphics output
   switching via xrandr or such, not at the time the monitor is
   physically plugged/unplugged.

2. At switching, the unplug event must be handled at first, and then
   the plug event.

3. At unplug, detach per_pin object properly from PCM.
   We currently just notify it via jack ctl, and doesn't care the
   rest.  Ideally, we should force to stop the PCM and detach
   internally from the assigned pin.

4. At plug, assign the monitor to the free per_pin object.

So what we've discussed is about the last step; how to map the new
monitor to per_pin object.  This requires the other steps beforehand
which assures a free per_pin is present at plug time.


Takashi

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Tuesday, October 13, 2015 5:21 PM
> To: Yang, Libin
> Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood, Liam
> R; alsa-devel@alsa-project.org; airlied@linux.ie
> Subject: Re: DP1.2 MST audio support discussion
> 
> On Tue, 13 Oct 2015 09:34:49 +0200,
> Yang, Libin wrote:
> >
> > > One could then allocate two extra PCMs from the start (9 and 10)
> to
> > > try
> > > in case the other PCM is busy (my preference), or one could steal
> one
> > > of
> > > the existing non-busy ones (Takashi's preference).
> >
> > We will create the PCMs based on converter. This means we will
> > create 3 PCMs. And it will not support dynamically allocating PCM.
> > As there are only 3 converters, no more PCMs will be supported.
> > Each PCM will use one converter. If 3 PCMs are all used, connecting
> > monitor will not create new PCM.
> >
> > Yes, if we are not using the PCM, we can re-assign the PCM to
> another
> > monitor. Currently, user can't decide which PCM is used for which
> > monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7
> is
> > assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
> > connected, no PCM is available, and driver don't know whether it
> > should steal one PCM for the monitor 4 and user can't change the
> > mapping currently.
> 
> Actually, there are a few things to implement properly:
> 
> 1. The plug/unplug events are triggered at the actual graphics output
>    switching via xrandr or such, not at the time the monitor is
>    physically plugged/unplugged.
> 
> 2. At switching, the unplug event must be handled at first, and then
>    the plug event.
> 
> 3. At unplug, detach per_pin object properly from PCM.
>    We currently just notify it via jack ctl, and doesn't care the
>    rest.  Ideally, we should force to stop the PCM and detach
>    internally from the assigned pin.

For the switching, if we stop the PCM, when the plug event
happens, does this mean we should play the sound from
the beginning for continue playing the sound? 

It seems users will more likely hope continue playing the sound?
Some video players may use audio clock to do the Audio-Video
Sync (I'm not very sure). If we stop the PCM, after the hotplug,
the video player will be stopped and must play the video from
the beginning?

Regards,
Libin

> 
> 4. At plug, assign the monitor to the free per_pin object.
> 
> So what we've discussed is about the last step; how to map the new
> monitor to per_pin object.  This requires the other steps beforehand
> which assures a free per_pin is present at plug time.
> 
> 
> Takashi

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Tue, 13 Oct 2015 14:31:39 +0200,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Tuesday, October 13, 2015 5:21 PM
> > To: Yang, Libin
> > Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood, Liam
> > R; alsa-devel@alsa-project.org; airlied@linux.ie
> > Subject: Re: DP1.2 MST audio support discussion
> > 
> > On Tue, 13 Oct 2015 09:34:49 +0200,
> > Yang, Libin wrote:
> > >
> > > > One could then allocate two extra PCMs from the start (9 and 10)
> > to
> > > > try
> > > > in case the other PCM is busy (my preference), or one could steal
> > one
> > > > of
> > > > the existing non-busy ones (Takashi's preference).
> > >
> > > We will create the PCMs based on converter. This means we will
> > > create 3 PCMs. And it will not support dynamically allocating PCM.
> > > As there are only 3 converters, no more PCMs will be supported.
> > > Each PCM will use one converter. If 3 PCMs are all used, connecting
> > > monitor will not create new PCM.
> > >
> > > Yes, if we are not using the PCM, we can re-assign the PCM to
> > another
> > > monitor. Currently, user can't decide which PCM is used for which
> > > monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7
> > is
> > > assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
> > > connected, no PCM is available, and driver don't know whether it
> > > should steal one PCM for the monitor 4 and user can't change the
> > > mapping currently.
> > 
> > Actually, there are a few things to implement properly:
> > 
> > 1. The plug/unplug events are triggered at the actual graphics output
> >    switching via xrandr or such, not at the time the monitor is
> >    physically plugged/unplugged.
> > 
> > 2. At switching, the unplug event must be handled at first, and then
> >    the plug event.
> > 
> > 3. At unplug, detach per_pin object properly from PCM.
> >    We currently just notify it via jack ctl, and doesn't care the
> >    rest.  Ideally, we should force to stop the PCM and detach
> >    internally from the assigned pin.
> 
> For the switching, if we stop the PCM, when the plug event
> happens, does this mean we should play the sound from
> the beginning for continue playing the sound? 
> 
> It seems users will more likely hope continue playing the sound?

The user is expected to restart the stream from the scratch instead.
My assumption is to handle it like a disconnection of a hotplug
device.

> Some video players may use audio clock to do the Audio-Video
> Sync (I'm not very sure). If we stop the PCM, after the hotplug,
> the video player will be stopped and must play the video from
> the beginning?

Yes.  Remember that it's a DP, i.e. always with graphics.  If you
switch the graphics, you'd need to do the full change in anyway.


Takashi

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Tuesday, October 13, 2015 10:04 PM
> To: Yang, Libin
> Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood, Liam
> R; alsa-devel@alsa-project.org; airlied@linux.ie
> Subject: Re: DP1.2 MST audio support discussion
> 
> On Tue, 13 Oct 2015 14:31:39 +0200,
> Yang, Libin wrote:
> >
> > Hi Takashi,
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Tuesday, October 13, 2015 5:21 PM
> > > To: Yang, Libin
> > > Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood,
> Liam
> > > R; alsa-devel@alsa-project.org; airlied@linux.ie
> > > Subject: Re: DP1.2 MST audio support discussion
> > >
> > > On Tue, 13 Oct 2015 09:34:49 +0200,
> > > Yang, Libin wrote:
> > > >
> > > > > One could then allocate two extra PCMs from the start (9 and
> 10)
> > > to
> > > > > try
> > > > > in case the other PCM is busy (my preference), or one could
> steal
> > > one
> > > > > of
> > > > > the existing non-busy ones (Takashi's preference).
> > > >
> > > > We will create the PCMs based on converter. This means we will
> > > > create 3 PCMs. And it will not support dynamically allocating PCM.
> > > > As there are only 3 converters, no more PCMs will be supported.
> > > > Each PCM will use one converter. If 3 PCMs are all used,
> connecting
> > > > monitor will not create new PCM.
> > > >
> > > > Yes, if we are not using the PCM, we can re-assign the PCM to
> > > another
> > > > monitor. Currently, user can't decide which PCM is used for which
> > > > monitor. Image the scenario PCM 3 is assigned to monitor 1,
> PCM 7
> > > is
> > > > assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4
> is
> > > > connected, no PCM is available, and driver don't know whether it
> > > > should steal one PCM for the monitor 4 and user can't change the
> > > > mapping currently.
> > >
> > > Actually, there are a few things to implement properly:
> > >
> > > 1. The plug/unplug events are triggered at the actual graphics
> output
> > >    switching via xrandr or such, not at the time the monitor is
> > >    physically plugged/unplugged.
> > >
> > > 2. At switching, the unplug event must be handled at first, and then
> > >    the plug event.
> > >
> > > 3. At unplug, detach per_pin object properly from PCM.
> > >    We currently just notify it via jack ctl, and doesn't care the
> > >    rest.  Ideally, we should force to stop the PCM and detach
> > >    internally from the assigned pin.
> >
> > For the switching, if we stop the PCM, when the plug event
> > happens, does this mean we should play the sound from
> > the beginning for continue playing the sound?
> >
> > It seems users will more likely hope continue playing the sound?
> 
> The user is expected to restart the stream from the scratch instead.
> My assumption is to handle it like a disconnection of a hotplug
> device.
> 
> > Some video players may use audio clock to do the Audio-Video
> > Sync (I'm not very sure). If we stop the PCM, after the hotplug,
> > the video player will be stopped and must play the video from
> > the beginning?
> 
> Yes.  Remember that it's a DP, i.e. always with graphics.  If you
> switch the graphics, you'd need to do the full change in anyway.

OK. I see. So besides we detach the PCM from the pin, how can
we stop the PCM clearly? Do we notify it to userspace and let 
userspace stop the PCM?

Regards,
Libin

> 
> 
> Takashi

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Tue, 13 Oct 2015 16:12:58 +0200,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Tuesday, October 13, 2015 10:04 PM
> > To: Yang, Libin
> > Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood, Liam
> > R; alsa-devel@alsa-project.org; airlied@linux.ie
> > Subject: Re: DP1.2 MST audio support discussion
> > 
> > On Tue, 13 Oct 2015 14:31:39 +0200,
> > Yang, Libin wrote:
> > >
> > > Hi Takashi,
> > >
> > > > -----Original Message-----
> > > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > > Sent: Tuesday, October 13, 2015 5:21 PM
> > > > To: Yang, Libin
> > > > Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood,
> > Liam
> > > > R; alsa-devel@alsa-project.org; airlied@linux.ie
> > > > Subject: Re: DP1.2 MST audio support discussion
> > > >
> > > > On Tue, 13 Oct 2015 09:34:49 +0200,
> > > > Yang, Libin wrote:
> > > > >
> > > > > > One could then allocate two extra PCMs from the start (9 and
> > 10)
> > > > to
> > > > > > try
> > > > > > in case the other PCM is busy (my preference), or one could
> > steal
> > > > one
> > > > > > of
> > > > > > the existing non-busy ones (Takashi's preference).
> > > > >
> > > > > We will create the PCMs based on converter. This means we will
> > > > > create 3 PCMs. And it will not support dynamically allocating PCM.
> > > > > As there are only 3 converters, no more PCMs will be supported.
> > > > > Each PCM will use one converter. If 3 PCMs are all used,
> > connecting
> > > > > monitor will not create new PCM.
> > > > >
> > > > > Yes, if we are not using the PCM, we can re-assign the PCM to
> > > > another
> > > > > monitor. Currently, user can't decide which PCM is used for which
> > > > > monitor. Image the scenario PCM 3 is assigned to monitor 1,
> > PCM 7
> > > > is
> > > > > assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4
> > is
> > > > > connected, no PCM is available, and driver don't know whether it
> > > > > should steal one PCM for the monitor 4 and user can't change the
> > > > > mapping currently.
> > > >
> > > > Actually, there are a few things to implement properly:
> > > >
> > > > 1. The plug/unplug events are triggered at the actual graphics
> > output
> > > >    switching via xrandr or such, not at the time the monitor is
> > > >    physically plugged/unplugged.
> > > >
> > > > 2. At switching, the unplug event must be handled at first, and then
> > > >    the plug event.
> > > >
> > > > 3. At unplug, detach per_pin object properly from PCM.
> > > >    We currently just notify it via jack ctl, and doesn't care the
> > > >    rest.  Ideally, we should force to stop the PCM and detach
> > > >    internally from the assigned pin.
> > >
> > > For the switching, if we stop the PCM, when the plug event
> > > happens, does this mean we should play the sound from
> > > the beginning for continue playing the sound?
> > >
> > > It seems users will more likely hope continue playing the sound?
> > 
> > The user is expected to restart the stream from the scratch instead.
> > My assumption is to handle it like a disconnection of a hotplug
> > device.
> > 
> > > Some video players may use audio clock to do the Audio-Video
> > > Sync (I'm not very sure). If we stop the PCM, after the hotplug,
> > > the video player will be stopped and must play the video from
> > > the beginning?
> > 
> > Yes.  Remember that it's a DP, i.e. always with graphics.  If you
> > switch the graphics, you'd need to do the full change in anyway.
> 
> OK. I see. So besides we detach the PCM from the pin, how can
> we stop the PCM clearly? Do we notify it to userspace and let 
> userspace stop the PCM?

A similar procedure like the hot unplug is needed.  Maybe an easy way
would be to issue snd_pcm_stop() but with SND_PCM_STATE_DISCONNECTED.
As the userspace notification, the jack event should suffice.

An open question is about the behavior at opening an unassigned pin.
So far, we don't care and allows to operate a PCM entry even if no
monitor is connected.  Is this still required for probing by PA?
Or should we better return an error if no monitor is connected (if the
information is reliable)?


Takashi

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Wednesday, October 14, 2015 12:20 AM
> To: Yang, Libin
> Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood, Liam
> R; alsa-devel@alsa-project.org; airlied@linux.ie
> Subject: Re: DP1.2 MST audio support discussion
> 
> On Tue, 13 Oct 2015 16:12:58 +0200,
> Yang, Libin wrote:
> >
> > Hi Takashi,
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Tuesday, October 13, 2015 10:04 PM
> > > To: Yang, Libin
> > > Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood,
> Liam
> > > R; alsa-devel@alsa-project.org; airlied@linux.ie
> > > Subject: Re: DP1.2 MST audio support discussion
> > >
> > > On Tue, 13 Oct 2015 14:31:39 +0200,
> > > Yang, Libin wrote:
> > > >
> > > > Hi Takashi,
> > > >
> > > > > -----Original Message-----
> > > > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > > > Sent: Tuesday, October 13, 2015 5:21 PM
> > > > > To: Yang, Libin
> > > > > Cc: David Henningsson; Lin, Mengdong; tanuk@iki.fi; Girdwood,
> > > Liam
> > > > > R; alsa-devel@alsa-project.org; airlied@linux.ie
> > > > > Subject: Re: DP1.2 MST audio support discussion
> > > > >
> > > > > On Tue, 13 Oct 2015 09:34:49 +0200,
> > > > > Yang, Libin wrote:
> > > > > >
> > > > > > > One could then allocate two extra PCMs from the start (9
> and
> > > 10)
> > > > > to
> > > > > > > try
> > > > > > > in case the other PCM is busy (my preference), or one could
> > > steal
> > > > > one
> > > > > > > of
> > > > > > > the existing non-busy ones (Takashi's preference).
> > > > > >
> > > > > > We will create the PCMs based on converter. This means we
> will
> > > > > > create 3 PCMs. And it will not support dynamically allocating
> PCM.
> > > > > > As there are only 3 converters, no more PCMs will be
> supported.
> > > > > > Each PCM will use one converter. If 3 PCMs are all used,
> > > connecting
> > > > > > monitor will not create new PCM.
> > > > > >
> > > > > > Yes, if we are not using the PCM, we can re-assign the PCM to
> > > > > another
> > > > > > monitor. Currently, user can't decide which PCM is used for
> which
> > > > > > monitor. Image the scenario PCM 3 is assigned to monitor 1,
> > > PCM 7
> > > > > is
> > > > > > assigned to monitor 2, PCM 8 is assigned to monitor 3.
> Monitor 4
> > > is
> > > > > > connected, no PCM is available, and driver don't know
> whether it
> > > > > > should steal one PCM for the monitor 4 and user can't change
> the
> > > > > > mapping currently.
> > > > >
> > > > > Actually, there are a few things to implement properly:
> > > > >
> > > > > 1. The plug/unplug events are triggered at the actual graphics
> > > output
> > > > >    switching via xrandr or such, not at the time the monitor is
> > > > >    physically plugged/unplugged.
> > > > >
> > > > > 2. At switching, the unplug event must be handled at first, and
> then
> > > > >    the plug event.
> > > > >
> > > > > 3. At unplug, detach per_pin object properly from PCM.
> > > > >    We currently just notify it via jack ctl, and doesn't care the
> > > > >    rest.  Ideally, we should force to stop the PCM and detach
> > > > >    internally from the assigned pin.
> > > >
> > > > For the switching, if we stop the PCM, when the plug event
> > > > happens, does this mean we should play the sound from
> > > > the beginning for continue playing the sound?
> > > >
> > > > It seems users will more likely hope continue playing the sound?
> > >
> > > The user is expected to restart the stream from the scratch instead.
> > > My assumption is to handle it like a disconnection of a hotplug
> > > device.
> > >
> > > > Some video players may use audio clock to do the Audio-Video
> > > > Sync (I'm not very sure). If we stop the PCM, after the hotplug,
> > > > the video player will be stopped and must play the video from
> > > > the beginning?
> > >
> > > Yes.  Remember that it's a DP, i.e. always with graphics.  If you
> > > switch the graphics, you'd need to do the full change in anyway.
> >
> > OK. I see. So besides we detach the PCM from the pin, how can
> > we stop the PCM clearly? Do we notify it to userspace and let
> > userspace stop the PCM?
> 
> A similar procedure like the hot unplug is needed.  Maybe an easy way
> would be to issue snd_pcm_stop() but with
> SND_PCM_STATE_DISCONNECTED.
> As the userspace notification, the jack event should suffice.

Get it. Thanks.

> 
> An open question is about the behavior at opening an unassigned pin.
> So far, we don't care and allows to operate a PCM entry even if no
> monitor is connected.  Is this still required for probing by PA?
> Or should we better return an error if no monitor is connected (if the
> information is reliable)?
> 
> 
> Takashi

Re: DP1.2 MST audio support discussion

[Raymond Yau]

> >
> > > One could then allocate two extra PCMs from the start (9 and 10) to
> > > try
> > > in case the other PCM is busy (my preference), or one could steal one
> > > of
> > > the existing non-busy ones (Takashi's preference).
> >
> > We will create the PCMs based on converter. This means we will
> > create 3 PCMs. And it will not support dynamically allocating PCM.
> > As there are only 3 converters, no more PCMs will be supported.
> > Each PCM will use one converter. If 3 PCMs are all used, connecting
> > monitor will not create new PCM.
> >
> > Yes, if we are not using the PCM, we can re-assign the PCM to another
> > monitor. Currently, user can't decide which PCM is used for which
> > monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7 is
> > assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
> > connected, no PCM is available, and driver don't know whether it
> > should steal one PCM for the monitor 4 and user can't change the
> > mapping currently.
>
> Actually, there are a few things to implement properly:
>
> 1. The plug/unplug events are triggered at the actual graphics output
>    switching via xrandr or such, not at the time the monitor is
>    physically plugged/unplugged.
>
> 2. At switching, the unplug event must be handled at first, and then
>    the plug event.
>
> 3. At unplug, detach per_pin object properly from PCM.
>    We currently just notify it via jack ctl, and doesn't care the
>    rest.  Ideally, we should force to stop the PCM and detach
>    internally from the assigned pin.
>
> 4. At plug, assign the monitor to the free per_pin object.
>
> So what we've discussed is about the last step; how to map the new
> monitor to per_pin object.  This requires the other steps beforehand
> which assures a free per_pin is present at plug time.
>

Do it mean that only one DP MST port and no HDMI port on the same graphic
card ?

If DP MST are dasiy chained, the unplug of the first monitor from Display
Port will cause all DP monitor in the dasiy chain disconnect

Re: DP1.2 MST audio support discussion

[Yang, Libin]

+ intel gfx experts.

Hi Raymond,


From: Raymond Yau [mailto:superquad.vortex2@gmail.com] 
Sent: Wednesday, October 14, 2015 7:52 AM
To: Takashi Iwai
Cc: ALSA Development Mailing List; David Henningsson; tanuk@iki.fi; airlied@linux.ie; Yang, Libin; Girdwood, Liam R; Lin, Mengdong
Subject: Re: [alsa-devel] DP1.2 MST audio support discussion


> >
> > > One could then allocate two extra PCMs from the start (9 and 10) to
> > > try
> > > in case the other PCM is busy (my preference), or one could steal one
> > > of
> > > the existing non-busy ones (Takashi's preference).
> >
> > We will create the PCMs based on converter. This means we will
> > create 3 PCMs. And it will not support dynamically allocating PCM.
> > As there are only 3 converters, no more PCMs will be supported.
> > Each PCM will use one converter. If 3 PCMs are all used, connecting
> > monitor will not create new PCM.
> >
> > Yes, if we are not using the PCM, we can re-assign the PCM to another
> > monitor. Currently, user can't decide which PCM is used for which
> > monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7 is
> > assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
> > connected, no PCM is available, and driver don't know whether it
> > should steal one PCM for the monitor 4 and user can't change the
> > mapping currently.
>
> Actually, there are a few things to implement properly:
>
> 1. The plug/unplug events are triggered at the actual graphics output
>    switching via xrandr or such, not at the time the monitor is
>    physically plugged/unplugged.
>
> 2. At switching, the unplug event must be handled at first, and then
>    the plug event.
>
> 3. At unplug, detach per_pin object properly from PCM.
>    We currently just notify it via jack ctl, and doesn't care the
>    rest.  Ideally, we should force to stop the PCM and detach
>    internally from the assigned pin.
>
> 4. At plug, assign the monitor to the free per_pin object.
>
> So what we've discussed is about the last step; how to map the new
> monitor to per_pin object.  This requires the other steps beforehand
> which assures a free per_pin is present at plug time.
>
Do it mean that only one DP MST port and no HDMI port on the same graphic card ?

[Libin] It support DP MST and HDMI both on the same graphic card. 
    On intel platform, it is using DDI port, support both DP and HDMI.

If DP MST are dasiy chained, the unplug of the first monitor from Display Port will cause all DP monitor in the dasiy chain disconnect 
[Libin] In this mode, multiple interrupts should occur?
    If so we can handle the daisy chained mode easily.
    Anyway, as the monitors are on the same pin,
    we can always know whether there is monitor on the pin.
    Thanks for reminding it.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Wed, 14 Oct 2015 01:52:08 +0200,
Raymond Yau wrote:
> 
> > >
> > > > One could then allocate two extra PCMs from the start (9 and 10) to
> > > > try
> > > > in case the other PCM is busy (my preference), or one could steal one
> > > > of
> > > > the existing non-busy ones (Takashi's preference).
> > >
> > > We will create the PCMs based on converter. This means we will
> > > create 3 PCMs. And it will not support dynamically allocating PCM.
> > > As there are only 3 converters, no more PCMs will be supported.
> > > Each PCM will use one converter. If 3 PCMs are all used, connecting
> > > monitor will not create new PCM.
> > >
> > > Yes, if we are not using the PCM, we can re-assign the PCM to another
> > > monitor. Currently, user can't decide which PCM is used for which
> > > monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7 is
> > > assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
> > > connected, no PCM is available, and driver don't know whether it
> > > should steal one PCM for the monitor 4 and user can't change the
> > > mapping currently.
> >
> > Actually, there are a few things to implement properly:
> >
> > 1. The plug/unplug events are triggered at the actual graphics output
> >    switching via xrandr or such, not at the time the monitor is
> >    physically plugged/unplugged.
> >
> > 2. At switching, the unplug event must be handled at first, and then
> >    the plug event.
> >
> > 3. At unplug, detach per_pin object properly from PCM.
> >    We currently just notify it via jack ctl, and doesn't care the
> >    rest.  Ideally, we should force to stop the PCM and detach
> >    internally from the assigned pin.
> >
> > 4. At plug, assign the monitor to the free per_pin object.
> >
> > So what we've discussed is about the last step; how to map the new
> > monitor to per_pin object.  This requires the other steps beforehand
> > which assures a free per_pin is present at plug time.
> >
> 
> Do it mean that only one DP MST port and no HDMI port on the same graphic
> card ?

No.

> If DP MST are dasiy chained, the unplug of the first monitor from Display
> Port will cause all DP monitor in the dasiy chain disconnect

Yes.


Takashi

Re: DP1.2 MST audio support discussion

[Raymond Yau]

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

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 ?

Will three three display port monitor playback devices always play
different stream even when the displays are in clone mode ?

>
> > If DP MST are dasiy chained, the unplug of the first monitor from
Display
> > Port will cause all DP monitor in the dasiy chain disconnect
>
> Yes.
>

Do the power off of the Display Port in the middle of the dasiy chain also
affect the last display port mointor in the dasiy chain ?

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

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.

> Will three three display port monitor playback devices always play
> different stream even when the displays are in clone mode ?

The clone mode is another messy part...

> > > If DP MST are dasiy chained, the unplug of the first monitor from
> Display
> > > Port will cause all DP monitor in the dasiy chain disconnect
> >
> > Yes.
> >
> 
> Do the power off of the Display Port in the middle of the dasiy chain also
> affect the last display port mointor in the dasiy chain ?

Possibly.  But it's not what we really care, as this is the thing the
graphics side should handle.


Takashi

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Friday, October 16, 2015 2:38 PM
> To: Raymond Yau
> Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin,
> Mengdong; Girdwood, Liam R; tanuk@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?

> 
> > Will three three display port monitor playback devices always play
> > different stream even when the displays are in clone mode ?
> 
> The clone mode is another messy part...
> 
> > > > If DP MST are dasiy chained, the unplug of the first monitor from
> > Display
> > > > Port will cause all DP monitor in the dasiy chain disconnect
> > >
> > > Yes.
> > >
> >
> > Do the power off of the Display Port in the middle of the dasiy chain
> also
> > affect the last display port mointor in the dasiy chain ?
> 
> Possibly.  But it's not what we really care, as this is the thing the
> graphics side should handle.
> 
> 
> Takashi

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Fri, 16 Oct 2015 10:51:30 +0200,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Friday, October 16, 2015 2:38 PM
> > To: Raymond Yau
> > Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin,
> > Mengdong; Girdwood, Liam R; tanuk@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.


Takashi

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi,


> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Friday, October 16, 2015 5:01 PM
> To: Yang, Libin
> Cc: Raymond Yau; ALSA Development Mailing List; airlied@linux.ie; Lin,
> Mengdong; Girdwood, Liam R; tanuk@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@suse.de]
> > > Sent: Friday, October 16, 2015 2:38 PM
> > > To: Raymond Yau
> > > Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin,
> > > Mengdong; Girdwood, Liam R; tanuk@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

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Friday, October 16, 2015 2:38 PM
> To: Raymond Yau
> Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin,
> Mengdong; Girdwood, Liam R; tanuk@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.
> 
> > Will three three display port monitor playback devices always play
> > different stream even when the displays are in clone mode ?
> 
> The clone mode is another messy part...

After checking internally, we will not support clone mode atm based
on the HW suggestion.

> 
> > > > If DP MST are dasiy chained, the unplug of the first monitor from
> > Display
> > > > Port will cause all DP monitor in the dasiy chain disconnect
> > >
> > > Yes.
> > >
> >
> > Do the power off of the Display Port in the middle of the dasiy chain
> also
> > affect the last display port mointor in the dasiy chain ?
> 
> Possibly.  But it's not what we really care, as this is the thing the
> graphics side should handle.
> 
> 
> Takashi

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Raymond,

> 
> From: Raymond Yau [mailto:superquad.vortex2@gmail.com]
> Sent: Friday, October 16, 2015 8:33 AM
> To: Takashi Iwai
> Cc: airlied@linux.ie; tanuk@iki.fi; David Henningsson; Yang, Libin; Lin,
> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> 
> > >
> > > 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
> 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 ?

For the jack name, what do you think if we change to 
"HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?

Regards,
Libin

> Will three three display port monitor playback devices always play
> different stream even when the displays are in clone mode ?
> >
> > > If DP MST are dasiy chained, the unplug of the first monitor from
> Display
> > > Port will cause all DP monitor in the dasiy chain disconnect
> >
> > Yes.
> >
> Do the power off of the Display Port in the middle of the dasiy chain
> also affect the last display port mointor in the dasiy chain ?

Re: DP1.2 MST audio support discussion

[David Henningsson]

On 2015-10-22 03:31, Yang, Libin wrote:
> Hi Raymond,
>
>>
>> From: Raymond Yau [mailto:superquad.vortex2@gmail.com]
>> Sent: Friday, October 16, 2015 8:33 AM
>> To: Takashi Iwai
>> Cc: airlied@linux.ie; tanuk@iki.fi; David Henningsson; Yang, Libin; Lin,
>> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
>>
>>
>>>>
>>>> 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
>> 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 ?
>
> For the jack name, what do you think if we change to
> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?

Yes, it will impact PulseAudio. It will require changes to files in

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Yang, Libin]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Thursday, October 22, 2015 2:52 PM
> To: Yang, Libin; Raymond Yau; Takashi Iwai
> Cc: airlied@linux.ie; tanuk@iki.fi; Lin, Mengdong; Girdwood, Liam R;
> ALSA Development Mailing List
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> 
> 
> On 2015-10-22 03:31, Yang, Libin wrote:
> > Hi Raymond,
> >
> >>
> >> From: Raymond Yau [mailto:superquad.vortex2@gmail.com]
> >> Sent: Friday, October 16, 2015 8:33 AM
> >> To: Takashi Iwai
> >> Cc: airlied@linux.ie; tanuk@iki.fi; David Henningsson; Yang, Libin;
> Lin,
> >> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
> >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> >>
> >>
> >>>>
> >>>> 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
> >> 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 ?
> >
> > For the jack name, what do you think if we change to
> > "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
> 
> Yes, it will impact PulseAudio. It will require changes to files in
> 
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/
> alsa/mixer/paths

So does this mean we should not change the name "HDMI/DP,pcm=3 Jack"
to "HDMI/DP,pin=n, dev=m Jack", otherwise the old PA will not work with
the new driver?

Regards,
Libin

> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[David Henningsson]

On 2015-10-22 08:56, Yang, Libin wrote:
>
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Thursday, October 22, 2015 2:52 PM
>> To: Yang, Libin; Raymond Yau; Takashi Iwai
>> Cc: airlied@linux.ie; tanuk@iki.fi; Lin, Mengdong; Girdwood, Liam R;
>> ALSA Development Mailing List
>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
>>
>>
>>
>> On 2015-10-22 03:31, Yang, Libin wrote:
>>> Hi Raymond,
>>>
>>>>
>>>> From: Raymond Yau [mailto:superquad.vortex2@gmail.com]
>>>> Sent: Friday, October 16, 2015 8:33 AM
>>>> To: Takashi Iwai
>>>> Cc: airlied@linux.ie; tanuk@iki.fi; David Henningsson; Yang, Libin;
>> Lin,
>>>> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
>>>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
>>>>
>>>>
>>>>>>
>>>>>> 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
>>>> 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 ?
>>>
>>> For the jack name, what do you think if we change to
>>> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
>>
>> Yes, it will impact PulseAudio. It will require changes to files in
>>
>> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/
>> alsa/mixer/paths
>
> So does this mean we should not change the name "HDMI/DP,pcm=3 Jack"
> to "HDMI/DP,pin=n, dev=m Jack", otherwise the old PA will not work with
> the new driver?

Yes. And I don't understand why you need to do it, either - if you have 
three display port monitors on one pin, then they will all get different 
PCMs (8, 9 and 10), and they will signal their Jack status through 
"HDMI/DP,pcm=8 Jack", "HDMI/DP,pcm=9 Jack" and "HDMI/DP,pcm=10 Jack".

Given that my proposed mapping algorithm will never change pin to PCM 
mapping (unless you have two displayport outputs and use MST on both), I 
think we can get away with not exposing the actual pin to userspace.
And should this later become necessary, we can add a separate kctl for that.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Yang, Libin]

> >>>> From: Raymond Yau [mailto:superquad.vortex2@gmail.com]
> >>>> Sent: Friday, October 16, 2015 8:33 AM
> >>>> To: Takashi Iwai
> >>>> Cc: airlied@linux.ie; tanuk@iki.fi; David Henningsson; Yang, Libin;
> >> Lin,
> >>>> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
> >>>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> >>>>
> >>>>
> >>>>>>
> >>>>>> 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
> >>>> 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 ?
> >>>
> >>> For the jack name, what do you think if we change to
> >>> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
> >>
> >> Yes, it will impact PulseAudio. It will require changes to files in
> >>
> >>
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/
> >> alsa/mixer/paths
> >
> > So does this mean we should not change the name "HDMI/DP,pcm=3
> Jack"
> > to "HDMI/DP,pin=n, dev=m Jack", otherwise the old PA will not work
> with
> > the new driver?
> 
> Yes. And I don't understand why you need to do it, either - if you have
> three display port monitors on one pin, then they will all get different
> PCMs (8, 9 and 10), and they will signal their Jack status through
> "HDMI/DP,pcm=8 Jack", "HDMI/DP,pcm=9 Jack" and
> "HDMI/DP,pcm=10 Jack".

OK, I see. Thanks. I will not change the jack kctl name.
BTW, the PCM number will be the same as converter, which means
it will be 3 on Intel platforms.

> 
> Given that my proposed mapping algorithm will never change pin to
> PCM
> mapping (unless you have two displayport outputs and use MST on
> both), I
> think we can get away with not exposing the actual pin to userspace.
> And should this later become necessary, we can add a separate kctl for
> that.

My current thought is to expose the same jack kctls (same number and
same name) to userspace while we will create hda_jack_tbl for each device
entry. When pcm is bound to the device entry, the corresponding
jack kctl will be bound to the device entry.

Regards,
Libin

> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: DP1.2 MST audio support discussion

[David Henningsson]

On 2015-10-22 09:40, Yang, Libin wrote:
>
>>>>>> From: Raymond Yau [mailto:superquad.vortex2@gmail.com]
>>>>>> Sent: Friday, October 16, 2015 8:33 AM
>>>>>> To: Takashi Iwai
>>>>>> Cc: airlied@linux.ie; tanuk@iki.fi; David Henningsson; Yang, Libin;
>>>> Lin,
>>>>>> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
>>>>>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>> 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 ?
>>>>>
>>>>> For the jack name, what do you think if we change to
>>>>> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
>>>>
>>>> Yes, it will impact PulseAudio. It will require changes to files in
>>>>
>>>>
>> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/
>>>> alsa/mixer/paths
>>>
>>> So does this mean we should not change the name "HDMI/DP,pcm=3
>> Jack"
>>> to "HDMI/DP,pin=n, dev=m Jack", otherwise the old PA will not work
>> with
>>> the new driver?
>>
>> Yes. And I don't understand why you need to do it, either - if you have
>> three display port monitors on one pin, then they will all get different
>> PCMs (8, 9 and 10), and they will signal their Jack status through
>> "HDMI/DP,pcm=8 Jack", "HDMI/DP,pcm=9 Jack" and
>> "HDMI/DP,pcm=10 Jack".
>
> OK, I see. Thanks. I will not change the jack kctl name.
> BTW, the PCM number will be the same as converter, which means
> it will be 3 on Intel platforms.

I'll try to explain my suggestion (which I believe Takashi's buying too) 
one more time then:

First, when a monitor is plugged in, we need to dynamically assign this 
monitor to five PCM devices. I believe this scheme will be best:

For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
For a monitor at dev index 1 (any pin), it will prefer PCM 9.
For a monitor at dev index 2 (any pin), it will prefer PCM 10.

For monitors at dev indices > 2 (can that happen?), or if the PCM is 
already assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
(Subject to discussion perhaps, I don't think the order matters too 
much, because conflicts will be rare in practice.)

The jack and ELD kctls - one per PCM device - will follow what monitor 
the PCM is currently assigned to. (kctls belonging to a PCM device that 
is unassigned will report presence_detect=0 and eld_valid=0.)

Then, at playback open time, a free converter node will be dynamically 
assigned to the PCM. If there are no free converter nodes, return -EBUSY.

Now remains the case when an unassigned PCM is opened. This needs 
additional thinking, but the more backwards compatibility we can keep 
for this case, the better. But I'm not sure about how possible it is to 
let streams "freewheel" in this new DSP MST world?

>> Given that my proposed mapping algorithm will never change pin to
>> PCM
>> mapping (unless you have two displayport outputs and use MST on
>> both), I
>> think we can get away with not exposing the actual pin to userspace.
>> And should this later become necessary, we can add a separate kctl for
>> that.
>
> My current thought is to expose the same jack kctls (same number and
> same name) to userspace while we will create hda_jack_tbl for each device
> entry. When pcm is bound to the device entry, the corresponding
> jack kctl will be bound to the device entry.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Yang, Libin]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Thursday, October 22, 2015 4:53 PM
> To: Yang, Libin; Raymond Yau; Takashi Iwai
> Cc: airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List;
> Girdwood, Liam R; Lin, Mengdong
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> 
> 
> On 2015-10-22 09:40, Yang, Libin wrote:
> >
> >>>>>> From: Raymond Yau [mailto:superquad.vortex2@gmail.com]
> >>>>>> Sent: Friday, October 16, 2015 8:33 AM
> >>>>>> To: Takashi Iwai
> >>>>>> Cc: airlied@linux.ie; tanuk@iki.fi; David Henningsson; Yang,
> Libin;
> >>>> Lin,
> >>>>>> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
> >>>>>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> >>>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>> 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
> >>>>>> 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 ?
> >>>>>
> >>>>> For the jack name, what do you think if we change to
> >>>>> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
> >>>>
> >>>> Yes, it will impact PulseAudio. It will require changes to files in
> >>>>
> >>>>
> >>
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/
> >>>> alsa/mixer/paths
> >>>
> >>> So does this mean we should not change the name
> "HDMI/DP,pcm=3
> >> Jack"
> >>> to "HDMI/DP,pin=n, dev=m Jack", otherwise the old PA will not
> work
> >> with
> >>> the new driver?
> >>
> >> Yes. And I don't understand why you need to do it, either - if you
> have
> >> three display port monitors on one pin, then they will all get
> different
> >> PCMs (8, 9 and 10), and they will signal their Jack status through
> >> "HDMI/DP,pcm=8 Jack", "HDMI/DP,pcm=9 Jack" and
> >> "HDMI/DP,pcm=10 Jack".
> >
> > OK, I see. Thanks. I will not change the jack kctl name.
> > BTW, the PCM number will be the same as converter, which means
> > it will be 3 on Intel platforms.
> 
> I'll try to explain my suggestion (which I believe Takashi's buying too)
> one more time then:
> 
> First, when a monitor is plugged in, we need to dynamically assign this
> monitor to five PCM devices. I believe this scheme will be best:
> 
> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> 
> For monitors at dev indices > 2 (can that happen?), or if the PCM is
> already assigned to something else, try PCMs in this order: 9, 10, 3, 7,
> 8.
> (Subject to discussion perhaps, I don't think the order matters too
> much, because conflicts will be rare in practice.)

Oh, it seems my understand is wrong. OK, so the pcm number will be:
Pin number + max (device entry number per pin) - 1. For example,
on intel platform, it is 5.

> 
> The jack and ELD kctls - one per PCM device - will follow what monitor
> the PCM is currently assigned to. (kctls belonging to a PCM device that
> is unassigned will report presence_detect=0 and eld_valid=0.)

It makes sense. This should be mostly friendly to userspace. I will do it.

> 
> Then, at playback open time, a free converter node will be dynamically
> assigned to the PCM. If there are no free converter nodes, return -
> EBUSY.

Yes, this is what I think.

> 
> Now remains the case when an unassigned PCM is opened. This needs
> additional thinking, but the more backwards compatibility we can keep
> for this case, the better. But I'm not sure about how possible it is to
> let streams "freewheel" in this new DSP MST world?

Do you mean playing on unassigned PCM should work as the monitor is
connected? I remember Takashi mentioned disconnecting monitor when
playback should trigger stop PCM. This case should follow the same policy
and return -ENODEV or -EINVAL?

> 
> >> Given that my proposed mapping algorithm will never change pin to
> >> PCM
> >> mapping (unless you have two displayport outputs and use MST on
> >> both), I
> >> think we can get away with not exposing the actual pin to
> userspace.
> >> And should this later become necessary, we can add a separate kctl
> for
> >> that.
> >
> > My current thought is to expose the same jack kctls (same number
> and
> > same name) to userspace while we will create hda_jack_tbl for each
> device
> > entry. When pcm is bound to the device entry, the corresponding
> > jack kctl will be bound to the device entry.
> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Thu, 22 Oct 2015 10:52:59 +0200,
David Henningsson wrote:
> 
> 
> 
> On 2015-10-22 09:40, Yang, Libin wrote:
> >
> >>>>>> From: Raymond Yau [mailto:superquad.vortex2@gmail.com]
> >>>>>> Sent: Friday, October 16, 2015 8:33 AM
> >>>>>> To: Takashi Iwai
> >>>>>> Cc: airlied@linux.ie; tanuk@iki.fi; David Henningsson; Yang, Libin;
> >>>> Lin,
> >>>>>> Mengdong; Girdwood, Liam R; ALSA Development Mailing List
> >>>>>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> >>>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>> 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
> >>>>>> 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 ?
> >>>>>
> >>>>> For the jack name, what do you think if we change to
> >>>>> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
> >>>>
> >>>> Yes, it will impact PulseAudio. It will require changes to files in
> >>>>
> >>>>
> >> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/
> >>>> alsa/mixer/paths
> >>>
> >>> So does this mean we should not change the name "HDMI/DP,pcm=3
> >> Jack"
> >>> to "HDMI/DP,pin=n, dev=m Jack", otherwise the old PA will not work
> >> with
> >>> the new driver?
> >>
> >> Yes. And I don't understand why you need to do it, either - if you have
> >> three display port monitors on one pin, then they will all get different
> >> PCMs (8, 9 and 10), and they will signal their Jack status through
> >> "HDMI/DP,pcm=8 Jack", "HDMI/DP,pcm=9 Jack" and
> >> "HDMI/DP,pcm=10 Jack".
> >
> > OK, I see. Thanks. I will not change the jack kctl name.
> > BTW, the PCM number will be the same as converter, which means
> > it will be 3 on Intel platforms.
> 
> I'll try to explain my suggestion (which I believe Takashi's buying too) 
> one more time then:
> 
> First, when a monitor is plugged in, we need to dynamically assign this 
> monitor to five PCM devices. I believe this scheme will be best:
> 
> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> 
> For monitors at dev indices > 2 (can that happen?), or if the PCM is 
> already assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
> (Subject to discussion perhaps, I don't think the order matters too 
> much, because conflicts will be rare in practice.)
> 
> The jack and ELD kctls - one per PCM device - will follow what monitor 
> the PCM is currently assigned to. (kctls belonging to a PCM device that 
> is unassigned will report presence_detect=0 and eld_valid=0.)
> 
> Then, at playback open time, a free converter node will be dynamically 
> assigned to the PCM. If there are no free converter nodes, return -EBUSY.
> 
> Now remains the case when an unassigned PCM is opened. This needs 
> additional thinking, but the more backwards compatibility we can keep 
> for this case, the better. But I'm not sure about how possible it is to 
> let streams "freewheel" in this new DSP MST world?

Well, the only question is how PA reacts if we return -ENODEV or
whatever for opening an unassigned PCM.  I thought PA relies on the
PCM open for probing streams at start?


Takashi

Re: DP1.2 MST audio support discussion

[Lin, Mengdong]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Thursday, October 22, 2015 4:53 PM

[snip] 

> I'll try to explain my suggestion (which I believe Takashi's buying too) one
> more time then:
> 
> First, when a monitor is plugged in, we need to dynamically assign this
> monitor to five PCM devices. I believe this scheme will be best:
> 
> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> 
> For monitors at dev indices > 2 (can that happen?), or if the PCM is already
> assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
> (Subject to discussion perhaps, I don't think the order matters too much,
> because conflicts will be rare in practice.)

Hi David,

Would you please clarify why PA needs such a fixed binding between PCM 3,7, 8 and pin 0x05,6,7?

And how will PA handle PCM 9,10 in a different way?
They are not bound to pins, and even not able to dev indexes. 
In practice, a platform will usually support either a DP port or a HDMI port from the Intel integrated GPU for cost consideration.
But theoretically i915 can use same device index on two different pins to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.

On Intel platforms, the max dev indices is 2. Not sure about Nvidia and AMD.

Thanks
Mengdong

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Fri, 23 Oct 2015 07:30:12 +0200,
Lin, Mengdong wrote:
> 
> > -----Original Message-----
> > From: David Henningsson [mailto:david.henningsson@canonical.com]
> > Sent: Thursday, October 22, 2015 4:53 PM
> 
> [snip] 
> 
> > I'll try to explain my suggestion (which I believe Takashi's buying too) one
> > more time then:
> > 
> > First, when a monitor is plugged in, we need to dynamically assign this
> > monitor to five PCM devices. I believe this scheme will be best:
> > 
> > For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> > For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> > For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> > For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> > For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> > 
> > For monitors at dev indices > 2 (can that happen?), or if the PCM is already
> > assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
> > (Subject to discussion perhaps, I don't think the order matters too much,
> > because conflicts will be rare in practice.)
> 
> Hi David,
> 
> Would you please clarify why PA needs such a fixed binding between PCM 3,7, 8 and pin 0x05,6,7?

It's not PA's requirement.  The only concern here is for people who
uses ALSA device directly, e.g. via aplay -Dhdmi:2.  The first monitor
is guaranteed to be mapped to the compatible position for such
people.

> And how will PA handle PCM 9,10 in a different way?
> They are not bound to pins, and even not able to dev indexes. 
> In practice, a platform will usually support either a DP port or a HDMI port from the Intel integrated GPU for cost consideration.
> But theoretically i915 can use same device index on two different pins to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.
> 
> On Intel platforms, the max dev indices is 2. Not sure about Nvidia and AMD.

The whole number should be min(pins * 2 - 1, pins * 64).  It's two for
Intel, and 7 or more on AMD/Nvidia.

As we've discussed, this "reserved" area is basically optional.  We
have them for keeping compatibility more easily.  Even if this are is
exhausted, you can still try to map to any empty slot as the last
resort.  So, in practice, maybe adding just two extra for this
reserved area should suffice.  That is, the scheme is:

- Try a static mapping at first
- If already occupied, try a dynamic mapping in reserved area
- If a dynamic mapping area is exhausted, try to find any empty slot

The device index number doesn't matter.  If it conflicts, try
another.


Takashi

Re: DP1.2 MST audio support discussion

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Friday, October 23, 2015 1:54 PM
> 
> On Fri, 23 Oct 2015 07:30:12 +0200,
> Lin, Mengdong wrote:
> >
> > > -----Original Message-----
> > > From: David Henningsson [mailto:david.henningsson@canonical.com]
> > > Sent: Thursday, October 22, 2015 4:53 PM
> >
> > [snip]
> >
> > > I'll try to explain my suggestion (which I believe Takashi's buying
> > > too) one more time then:
> > >
> > > First, when a monitor is plugged in, we need to dynamically assign
> > > this monitor to five PCM devices. I believe this scheme will be best:
> > >
> > > For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> > > For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> > > For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> > > For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> > > For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> > >
> > > For monitors at dev indices > 2 (can that happen?), or if the PCM is
> > > already assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
> > > (Subject to discussion perhaps, I don't think the order matters too
> > > much, because conflicts will be rare in practice.)
> >
> > Hi David,
> >
> > Would you please clarify why PA needs such a fixed binding between PCM
> 3,7, 8 and pin 0x05,6,7?
> 
> It's not PA's requirement.  The only concern here is for people who uses
> ALSA device directly, e.g. via aplay -Dhdmi:2.  The first monitor is
> guaranteed to be mapped to the compatible position for such people.

Excuse me, could you share more background info here?
Even before DP MST support, it seems that such people need to know what pin is used to connect a monitor. Why?

The user can enumerate the PCM devices, and the PCM's jack ioctl can show whether a monitor is available behind this PCM device, no matter the driver uses fixed or dynamic binding between the PCM and pins.
So people can always choose a PCM to use a monitor. I feel they need not care which pin is used for the monitor.

> > And how will PA handle PCM 9,10 in a different way?
> > They are not bound to pins, and even not able to dev indexes.
> > In practice, a platform will usually support either a DP port or a HDMI port
> from the Intel integrated GPU for cost consideration.
> > But theoretically i915 can use same device index on two different pins to
> connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06,
> dev index 2 for the other.
> >
> > On Intel platforms, the max dev indices is 2. Not sure about Nvidia and
> AMD.
> 
> The whole number should be min(pins * 2 - 1, pins * 64).  It's two for Intel,
> and 7 or more on AMD/Nvidia.
> 
> As we've discussed, this "reserved" area is basically optional.  We have them
> for keeping compatibility more easily.  Even if this are is exhausted, you can
> still try to map to any empty slot as the last resort.  So, in practice, maybe
> adding just two extra for this reserved area should suffice.  That is, the
> scheme is:
> 
> - Try a static mapping at first
> - If already occupied, try a dynamic mapping in reserved area
> - If a dynamic mapping area is exhausted, try to find any empty slot
> 
> The device index number doesn't matter.  If it conflicts, try another.
> 

Thanks for your clarification! This scheme should work.
I misunderstood "prefer" as "fixed binding" in David's suggestion.

Regards
Mengdong

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Fri, 23 Oct 2015 10:35:26 +0200,
Lin, Mengdong wrote:
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Friday, October 23, 2015 1:54 PM
> > 
> > On Fri, 23 Oct 2015 07:30:12 +0200,
> > Lin, Mengdong wrote:
> > >
> > > > -----Original Message-----
> > > > From: David Henningsson [mailto:david.henningsson@canonical.com]
> > > > Sent: Thursday, October 22, 2015 4:53 PM
> > >
> > > [snip]
> > >
> > > > I'll try to explain my suggestion (which I believe Takashi's buying
> > > > too) one more time then:
> > > >
> > > > First, when a monitor is plugged in, we need to dynamically assign
> > > > this monitor to five PCM devices. I believe this scheme will be best:
> > > >
> > > > For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> > > > For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> > > > For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> > > > For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> > > > For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> > > >
> > > > For monitors at dev indices > 2 (can that happen?), or if the PCM is
> > > > already assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
> > > > (Subject to discussion perhaps, I don't think the order matters too
> > > > much, because conflicts will be rare in practice.)
> > >
> > > Hi David,
> > >
> > > Would you please clarify why PA needs such a fixed binding between PCM
> > 3,7, 8 and pin 0x05,6,7?
> > 
> > It's not PA's requirement.  The only concern here is for people who uses
> > ALSA device directly, e.g. via aplay -Dhdmi:2.  The first monitor is
> > guaranteed to be mapped to the compatible position for such people.
> 
> Excuse me, could you share more background info here?
> Even before DP MST support, it seems that such people need to know what pin is used to connect a monitor. Why?

On the existing machines, if you connect to a certain DP port, it's
always assigned to the same device.  This is guaranteed, so it's
perfectly fine to use this device statically for your purpose.

> The user can enumerate the PCM devices, and the PCM's jack ioctl can show whether a monitor is available behind this PCM device, no matter the driver uses fixed or dynamic binding between the PCM and pins.
> So people can always choose a PCM to use a monitor. I feel they need not care which pin is used for the monitor.

People *can* choose, but it doesn't mean people *must* reselect
another number out of sudden.  If they have to, it may be called a
regression.


Takashi

Re: DP1.2 MST audio support discussion

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Friday, October 23, 2015 4:44 PM
> 
> On Fri, 23 Oct 2015 10:35:26 +0200,
> Lin, Mengdong wrote:
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Friday, October 23, 2015 1:54 PM
> > >
> > > On Fri, 23 Oct 2015 07:30:12 +0200,
> > > Lin, Mengdong wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: David Henningsson
> [mailto:david.henningsson@canonical.com]
> > > > > Sent: Thursday, October 22, 2015 4:53 PM
> > > >
> > > > [snip]
> > > >
> > > > > I'll try to explain my suggestion (which I believe Takashi's
> > > > > buying
> > > > > too) one more time then:
> > > > >
> > > > > First, when a monitor is plugged in, we need to dynamically
> > > > > assign this monitor to five PCM devices. I believe this scheme will be
> best:
> > > > >
> > > > > For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> > > > > For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> > > > > For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> > > > > For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> > > > > For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> > > > >
> > > > > For monitors at dev indices > 2 (can that happen?), or if the
> > > > > PCM is already assigned to something else, try PCMs in this order: 9,
> 10, 3, 7, 8.
> > > > > (Subject to discussion perhaps, I don't think the order matters
> > > > > too much, because conflicts will be rare in practice.)
> > > >
> > > > Hi David,
> > > >
> > > > Would you please clarify why PA needs such a fixed binding between
> > > > PCM
> > > 3,7, 8 and pin 0x05,6,7?
> > >
> > > It's not PA's requirement.  The only concern here is for people who
> > > uses ALSA device directly, e.g. via aplay -Dhdmi:2.  The first
> > > monitor is guaranteed to be mapped to the compatible position for such
> people.
> >
> > Excuse me, could you share more background info here?
> > Even before DP MST support, it seems that such people need to know what
> pin is used to connect a monitor. Why?
> 
> On the existing machines, if you connect to a certain DP port, it's always
> assigned to the same device.  This is guaranteed, so it's perfectly fine to use
> this device statically for your purpose.
> 
> > The user can enumerate the PCM devices, and the PCM's jack ioctl can
> show whether a monitor is available behind this PCM device, no matter the
> driver uses fixed or dynamic binding between the PCM and pins.
> > So people can always choose a PCM to use a monitor. I feel they need not
> care which pin is used for the monitor.
> 
> People *can* choose, but it doesn't mean people *must* reselect another
> number out of sudden.  If they have to, it may be called a regression.

Okay. So the target is trying to assure a monitor uses the same PCM device statically as long as it's physically connected, over display mode change and power cycle.
And your and David's scheme to add 2 extra PCM devices in the reserved area should assure this for common configurations on Intel platforms, usually at most 1 DP + 1 HDMI.

We can check the length of device entries for a pin and add (Len -1) PCM devices. This can also work for Nvidia & AMD.

Thanks again for your clarification.

Regards
Mengdong
 

Re: DP1.2 MST audio support discussion

[Raymond Yau]

> >
> > > I'll try to explain my suggestion (which I believe Takashi's buying
too) one
> > > more time then:
> > >
> > > First, when a monitor is plugged in, we need to dynamically assign
this
> > > monitor to five PCM devices. I believe this scheme will be best:
> > >
> > > For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> > > For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> > > For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> > > For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> > > For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> > >
> > > For monitors at dev indices > 2 (can that happen?), or if the PCM is
already
> > > assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
> > > (Subject to discussion perhaps, I don't think the order matters too
much,
> > > because conflicts will be rare in practice.)
> >
> > Hi David,
> >
> > Would you please clarify why PA needs such a fixed binding between PCM
3,7, 8 and pin 0x05,6,7?
>
> It's not PA's requirement.  The only concern here is for people who
> uses ALSA device directly, e.g. via aplay -Dhdmi:2.  The first monitor
> is guaranteed to be mapped to the compatible position for such
> people.
>
> > And how will PA handle PCM 9,10 in a different way?
> > They are not bound to pins, and even not able to dev indexes.
> > In practice, a platform will usually support either a DP port or a HDMI
port from the Intel integrated GPU for cost consideration.
> > But theoretically i915 can use same device index on two different pins
to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin
0x06, dev index 2 for the other.
> >
> > On Intel platforms, the max dev indices is 2. Not sure about Nvidia and
AMD.
>
> The whole number should be min(pins * 2 - 1, pins * 64).  It's two for
> Intel, and 7 or more on AMD/Nvidia.
>
> As we've discussed, this "reserved" area is basically optional.  We
> have them for keeping compatibility more easily.  Even if this are is
> exhausted, you can still try to map to any empty slot as the last
> resort.  So, in practice, maybe adding just two extra for this
> reserved area should suffice.  That is, the scheme is:
>
> - Try a static mapping at first
> - If already occupied, try a dynamic mapping in reserved area
> - If a dynamic mapping area is exhausted, try to find any empty slot
>
> The device index number doesn't matter.  If it conflicts, try
> another.
>
>

How do those pcm assigned when the controller have HDMI and two display
ports ?

http://www.intel.com/support/motherboards/desktop/sb/CS-034199.htm

Intel® NUC Kit DC53427HYE and Intel® NUC Board D53427RKE

In this configuration, the two displays that you connect to the mini
DisplayPort ports must be native DisplayPort-capable. Adapters that change
DisplayPort to HDMI or DVI will not work. It is also best that the first
display be HDMI without any adapters.

First display HDMI on Intel NUC connected to HDMI or DVI on monitor/TV
Max resolution: 1920x1200
Second display Mini-DisplayPort 1 on Intel NUC connected to DisplayPort on
monitor/TV
Max resolution: 1920x1200
Third display Mini-DisplayPort 2 on Intel NUC connected to DisplayPort on
monitor/TV
Max resolution: 1920x1200
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: DP1.2 MST audio support discussion

[David Henningsson]

On 2015-10-23 07:30, Lin, Mengdong wrote:
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Thursday, October 22, 2015 4:53 PM
>
> [snip]
>
>> I'll try to explain my suggestion (which I believe Takashi's buying too) one
>> more time then:
>>
>> First, when a monitor is plugged in, we need to dynamically assign this
>> monitor to five PCM devices. I believe this scheme will be best:
>>
>> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
>> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
>> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
>> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
>> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
>>
>> For monitors at dev indices > 2 (can that happen?), or if the PCM is already
>> assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
>> (Subject to discussion perhaps, I don't think the order matters too much,
>> because conflicts will be rare in practice.)
>
> Hi David,
>
> Would you please clarify why PA needs such a fixed binding between PCM 3,7, 8 and pin 0x05,6,7?

PulseAudio saves information about profile and volume, and does so on 
what in PA terminology is called a "port". PA binds this port to a 
specific Jack kctl and a PCM device. How this fits together is 
configured in the files in /usr/share/pulseaudio/alsa-mixer/ .

E g, if both one HDMI and one DP monitor are both connected, the user 
might set the volume (through PA) of the HDMI monitor to high and the DP 
monitor to low. The user then reboots. Now, the PCM-to-monitor (and Jack 
kctl-to-monitor) mapping needs to remain the same after a reboot, 
otherwise PA might restore the volume to the wrong monitor.

> And how will PA handle PCM 9,10 in a different way?

PA will handle PCM 9 and 10 in the same way.

> They are not bound to pins, and even not able to dev indexes.
> In practice, a platform will usually support either a DP port or a HDMI port from the Intel integrated GPU for cost consideration.
> But theoretically i915 can use same device index on two different pins to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.

In theory, there are certainly cases where the PCM device allocation can 
cause problems for PA. What I'm trying to achieve is that these cases 
will be so few that no one will ever notice.

> On Intel platforms, the max dev indices is 2. Not sure about Nvidia and AMD.

Ok, thanks for the clarification.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Lin, Mengdong]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Friday, October 23, 2015 6:56 PM
> 
> On 2015-10-23 07:30, Lin, Mengdong wrote:
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson@canonical.com]
> >> Sent: Thursday, October 22, 2015 4:53 PM
> >
> > [snip]
> >
> >> I'll try to explain my suggestion (which I believe Takashi's buying
> >> too) one more time then:
> >>
> >> First, when a monitor is plugged in, we need to dynamically assign
> >> this monitor to five PCM devices. I believe this scheme will be best:
> >>
> >> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> >> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> >> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> >> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> >> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> >>
> >> For monitors at dev indices > 2 (can that happen?), or if the PCM is
> >> already assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8.
> >> (Subject to discussion perhaps, I don't think the order matters too
> >> much, because conflicts will be rare in practice.)
> >
> > Hi David,
> >
> > Would you please clarify why PA needs such a fixed binding between PCM
> 3,7, 8 and pin 0x05,6,7?
> 
> PulseAudio saves information about profile and volume, and does so on
> what in PA terminology is called a "port". PA binds this port to a specific Jack
> kctl and a PCM device. How this fits together is configured in the files in
> /usr/share/pulseaudio/alsa-mixer/ .
> 
> E g, if both one HDMI and one DP monitor are both connected, the user
> might set the volume (through PA) of the HDMI monitor to high and the DP
> monitor to low. The user then reboots. Now, the PCM-to-monitor (and Jack
> kctl-to-monitor) mapping needs to remain the same after a reboot,
> otherwise PA might restore the volume to the wrong monitor.

I see. Thank you for the info!
Random binding can break static mapping since the order of hot-plug unsol events is out of our control.

> 
> > And how will PA handle PCM 9,10 in a different way?
> 
> PA will handle PCM 9 and 10 in the same way.
> 
> > They are not bound to pins, and even not able to dev indexes.
> > In practice, a platform will usually support either a DP port or a HDMI port
> from the Intel integrated GPU for cost consideration.
> > But theoretically i915 can use same device index on two different pins to
> connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06,
> dev index 2 for the other.
> 
> In theory, there are certainly cases where the PCM device allocation can
> cause problems for PA. What I'm trying to achieve is that these cases will be
> so few that no one will ever notice.

I agree. Your suggestion can keep static mapping between monitors and PCM devices during various display mode change and power cycle for common use cases.

Regards
Mengdong

> 
> > On Intel platforms, the max dev indices is 2. Not sure about Nvidia and
> AMD.
> 
> Ok, thanks for the clarification.
> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi and David,

There are still some opens. Would you please help to comment?

1. SPDIF kctl.
This SPDIF number will be the same as PCM and be bound to the PCM.
The pin nid of SPDIF will not be initialized. And the pin nid will be assigned
After PCM is bound to the pin. (How to assign?)

2. chmap. 
The chmap will use the old method. Each virtual pin has its own chmap.

3. lock.
When accessing the register, the device entries in the same pin will impact on
each other. So when operating on a device entry, it need acquire a lock.
Do we need create each lock for each pin or just use one lock for all pins?

4. power management
If we close the PCM when disconnecting monitor, the driver will return 
-ENODEV, and we assume user space will close the PCM at once .
Thus the refcount will decrease automatically. So the codec has a chance
to enter D3 and release the shared power with GPU. GPU requires to
release the power as soon as the monitor is disconnected.
 

Regards,
Libin


> -----Original Message-----
> From: Lin, Mengdong
> Sent: Friday, October 23, 2015 8:35 PM
> To: David Henningsson; Yang, Libin; Raymond Yau; Takashi Iwai
> Cc: airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List;
> Girdwood, Liam R
> Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> 
> > -----Original Message-----
> > From: David Henningsson [mailto:david.henningsson@canonical.com]
> > Sent: Friday, October 23, 2015 6:56 PM
> >
> > On 2015-10-23 07:30, Lin, Mengdong wrote:
> > >> -----Original Message-----
> > >> From: David Henningsson
> [mailto:david.henningsson@canonical.com]
> > >> Sent: Thursday, October 22, 2015 4:53 PM
> > >
> > > [snip]
> > >
> > >> I'll try to explain my suggestion (which I believe Takashi's buying
> > >> too) one more time then:
> > >>
> > >> First, when a monitor is plugged in, we need to dynamically assign
> > >> this monitor to five PCM devices. I believe this scheme will be best:
> > >>
> > >> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> > >> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> > >> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> > >> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> > >> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> > >>
> > >> For monitors at dev indices > 2 (can that happen?), or if the PCM is
> > >> already assigned to something else, try PCMs in this order: 9, 10, 3,
> 7, 8.
> > >> (Subject to discussion perhaps, I don't think the order matters too
> > >> much, because conflicts will be rare in practice.)
> > >
> > > Hi David,
> > >
> > > Would you please clarify why PA needs such a fixed binding
> between PCM
> > 3,7, 8 and pin 0x05,6,7?
> >
> > PulseAudio saves information about profile and volume, and does so
> on
> > what in PA terminology is called a "port". PA binds this port to a
> specific Jack
> > kctl and a PCM device. How this fits together is configured in the files
> in
> > /usr/share/pulseaudio/alsa-mixer/ .
> >
> > E g, if both one HDMI and one DP monitor are both connected, the
> user
> > might set the volume (through PA) of the HDMI monitor to high and
> the DP
> > monitor to low. The user then reboots. Now, the PCM-to-monitor
> (and Jack
> > kctl-to-monitor) mapping needs to remain the same after a reboot,
> > otherwise PA might restore the volume to the wrong monitor.
> 
> I see. Thank you for the info!
> Random binding can break static mapping since the order of hot-plug
> unsol events is out of our control.
> 
> >
> > > And how will PA handle PCM 9,10 in a different way?
> >
> > PA will handle PCM 9 and 10 in the same way.
> >
> > > They are not bound to pins, and even not able to dev indexes.
> > > In practice, a platform will usually support either a DP port or a
> HDMI port
> > from the Intel integrated GPU for cost consideration.
> > > But theoretically i915 can use same device index on two different
> pins to
> > connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin
> 0x06,
> > dev index 2 for the other.
> >
> > In theory, there are certainly cases where the PCM device allocation
> can
> > cause problems for PA. What I'm trying to achieve is that these cases
> will be
> > so few that no one will ever notice.
> 
> I agree. Your suggestion can keep static mapping between monitors
> and PCM devices during various display mode change and power cycle
> for common use cases.
> 
> Regards
> Mengdong
> 
> >
> > > On Intel platforms, the max dev indices is 2. Not sure about Nvidia
> and
> > AMD.
> >
> > Ok, thanks for the clarification.
> >
> > --
> > David Henningsson, Canonical Ltd.
> > https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Tue, 27 Oct 2015 09:45:17 +0100,
Yang, Libin wrote:
> 
> Hi Takashi and David,
> 
> There are still some opens. Would you please help to comment?
> 
> 1. SPDIF kctl.
> This SPDIF number will be the same as PCM and be bound to the PCM.
> The pin nid of SPDIF will not be initialized. And the pin nid will be assigned
> After PCM is bound to the pin. (How to assign?)

I don't understand the question.  Could you elaborate?

> 2. chmap. 
> The chmap will use the old method. Each virtual pin has its own chmap.

Yes, and this doesn't change.  The chmap is assigned to each PCM
stream, basically, so it's tied to the assigned MST dev.

> 3. lock.
> When accessing the register, the device entries in the same pin will impact on
> each other. So when operating on a device entry, it need acquire a lock.
> Do we need create each lock for each pin or just use one lock for all pins?

It's is no big deal in either way, just choose the simpler one.

> 4. power management
> If we close the PCM when disconnecting monitor, the driver will return 
> -ENODEV, and we assume user space will close the PCM at once .

... if we implement it.  Actually this behavior (returning -ENODEV) is
not mandatory and needs investigation beforehand, whether this breaks
any applications, especially PA.

> Thus the refcount will decrease automatically. So the codec has a chance
> to enter D3 and release the shared power with GPU. GPU requires to
> release the power as soon as the monitor is disconnected.

Is this a problem?  The PM scheme doesn't change, after all.


Takashi

> 
> Regards,
> Libin
> 
> 
> > -----Original Message-----
> > From: Lin, Mengdong
> > Sent: Friday, October 23, 2015 8:35 PM
> > To: David Henningsson; Yang, Libin; Raymond Yau; Takashi Iwai
> > Cc: airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List;
> > Girdwood, Liam R
> > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> > 
> > > -----Original Message-----
> > > From: David Henningsson [mailto:david.henningsson@canonical.com]
> > > Sent: Friday, October 23, 2015 6:56 PM
> > >
> > > On 2015-10-23 07:30, Lin, Mengdong wrote:
> > > >> -----Original Message-----
> > > >> From: David Henningsson
> > [mailto:david.henningsson@canonical.com]
> > > >> Sent: Thursday, October 22, 2015 4:53 PM
> > > >
> > > > [snip]
> > > >
> > > >> I'll try to explain my suggestion (which I believe Takashi's buying
> > > >> too) one more time then:
> > > >>
> > > >> First, when a monitor is plugged in, we need to dynamically assign
> > > >> this monitor to five PCM devices. I believe this scheme will be best:
> > > >>
> > > >> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> > > >> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> > > >> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> > > >> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> > > >> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> > > >>
> > > >> For monitors at dev indices > 2 (can that happen?), or if the PCM is
> > > >> already assigned to something else, try PCMs in this order: 9, 10, 3,
> > 7, 8.
> > > >> (Subject to discussion perhaps, I don't think the order matters too
> > > >> much, because conflicts will be rare in practice.)
> > > >
> > > > Hi David,
> > > >
> > > > Would you please clarify why PA needs such a fixed binding
> > between PCM
> > > 3,7, 8 and pin 0x05,6,7?
> > >
> > > PulseAudio saves information about profile and volume, and does so
> > on
> > > what in PA terminology is called a "port". PA binds this port to a
> > specific Jack
> > > kctl and a PCM device. How this fits together is configured in the files
> > in
> > > /usr/share/pulseaudio/alsa-mixer/ .
> > >
> > > E g, if both one HDMI and one DP monitor are both connected, the
> > user
> > > might set the volume (through PA) of the HDMI monitor to high and
> > the DP
> > > monitor to low. The user then reboots. Now, the PCM-to-monitor
> > (and Jack
> > > kctl-to-monitor) mapping needs to remain the same after a reboot,
> > > otherwise PA might restore the volume to the wrong monitor.
> > 
> > I see. Thank you for the info!
> > Random binding can break static mapping since the order of hot-plug
> > unsol events is out of our control.
> > 
> > >
> > > > And how will PA handle PCM 9,10 in a different way?
> > >
> > > PA will handle PCM 9 and 10 in the same way.
> > >
> > > > They are not bound to pins, and even not able to dev indexes.
> > > > In practice, a platform will usually support either a DP port or a
> > HDMI port
> > > from the Intel integrated GPU for cost consideration.
> > > > But theoretically i915 can use same device index on two different
> > pins to
> > > connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin
> > 0x06,
> > > dev index 2 for the other.
> > >
> > > In theory, there are certainly cases where the PCM device allocation
> > can
> > > cause problems for PA. What I'm trying to achieve is that these cases
> > will be
> > > so few that no one will ever notice.
> > 
> > I agree. Your suggestion can keep static mapping between monitors
> > and PCM devices during various display mode change and power cycle
> > for common use cases.
> > 
> > Regards
> > Mengdong
> > 
> > >
> > > > On Intel platforms, the max dev indices is 2. Not sure about Nvidia
> > and
> > > AMD.
> > >
> > > Ok, thanks for the clarification.
> > >
> > > --
> > > David Henningsson, Canonical Ltd.
> > > https://launchpad.net/~diwic
> 

Re: DP1.2 MST audio support discussion

[Raymond Yau]

> >
> > There are still some opens. Would you please help to comment?
> >
> > 1. SPDIF kctl.
> > This SPDIF number will be the same as PCM and be bound to the PCM.
> > The pin nid of SPDIF will not be initialized. And the pin nid will be
assigned
> > After PCM is bound to the pin. (How to assign?)
>
> I don't understand the question.  Could you elaborate?

Are there any difference between three display ports in dasiy chain ?

As they are physically connected to the same complex, do they have own
playback switches or only one mute switch for three displayports ?

Re: DP1.2 MST audio support discussion

[Yang, Libin]

> -----Original Message-----
> From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-
> bounces@alsa-project.org] On Behalf Of Raymond Yau
> Sent: Sunday, November 01, 2015 4:53 PM
> To: Takashi Iwai
> Cc: Yang, Libin; ALSA Development Mailing List; airlied@linux.ie; Lin,
> Mengdong; Girdwood, Liam R; tanuk@iki.fi; Lu, Han; David
> Henningsson
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> > >
> > > There are still some opens. Would you please help to comment?
> > >
> > > 1. SPDIF kctl.
> > > This SPDIF number will be the same as PCM and be bound to the
> PCM.
> > > The pin nid of SPDIF will not be initialized. And the pin nid will be
> assigned
> > > After PCM is bound to the pin. (How to assign?)
> >
> > I don't understand the question.  Could you elaborate?
> 
> Are there any difference between three display ports in dasiy chain ?
> 
> As they are physically connected to the same complex, do they have
> own
> playback switches or only one mute switch for three displayports ?

I have tried: 2 monitors are connected to a DP MST hub, and the DP
MST hub is connected the computer. Each PCM can be muted
independently. 

I haven't tried: the first monitor is connected the computer
and another monitor is connected to the first monitor.

Suppose it should be the same (I'm not very sure).
As you know, we use converter to control the mute. Each 
PCM/device entry uses a different converter.

Regards,
Libin

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: DP1.2 MST audio support discussion

[Yang, Libin]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Friday, October 30, 2015 7:27 PM
> To: Yang, Libin
> Cc: Lin, Mengdong; David Henningsson; Raymond Yau; airlied@linux.ie;
> tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu,
> Han
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> On Tue, 27 Oct 2015 09:45:17 +0100,
> Yang, Libin wrote:
> >
> > Hi Takashi and David,
> >
> > There are still some opens. Would you please help to comment?
> >
> > 1. SPDIF kctl.
> > This SPDIF number will be the same as PCM and be bound to the PCM.
> > The pin nid of SPDIF will not be initialized. And the pin nid will be
> assigned
> > After PCM is bound to the pin. (How to assign?)
> 
> I don't understand the question.  Could you elaborate?

In alsamixer for HDMI, we can see S/PDIF ctl to control 
mute/unmute. Also in driver, we can see it creates the 
ctls with snd_hda_create_dig_out_ctls() in build_controls() 
based on pin number. I wonder whether user space use 
these ctls based on pin or pcm? Suppose it should be also 
based on PCM, right?

> 
> > 2. chmap.
> > The chmap will use the old method. Each virtual pin has its own
> chmap.
> 
> Yes, and this doesn't change.  The chmap is assigned to each PCM
> stream, basically, so it's tied to the assigned MST dev.

Thanks. 

> 
> > 3. lock.
> > When accessing the register, the device entries in the same pin will
> impact on
> > each other. So when operating on a device entry, it need acquire a
> lock.
> > Do we need create each lock for each pin or just use one lock for all
> pins?
> 
> It's is no big deal in either way, just choose the simpler one.

Get it. Thanks.

> 
> > 4. power management
> > If we close the PCM when disconnecting monitor, the driver will
> return
> > -ENODEV, and we assume user space will close the PCM at once .
> 
> ... if we implement it.  Actually this behavior (returning -ENODEV) is
> not mandatory and needs investigation beforehand, whether this
> breaks
> any applications, especially PA.

Yes. I heard that PA has dummy PCM and when there is no HW to
play the audio, PA can smoothly move the PCM from HW to dummy
PCM. If it's true, stopping PCM will not break PA, I think.

> 
> > Thus the refcount will decrease automatically. So the codec has a
> chance
> > to enter D3 and release the shared power with GPU. GPU requires to
> > release the power as soon as the monitor is disconnected.
> 
> Is this a problem?  The PM scheme doesn't change, after all.

Get it. Thanks.

Regards,
Libin

> 
> 
> Takashi
> 
> >
> > Regards,
> > Libin
> >
> >
> > > -----Original Message-----
> > > From: Lin, Mengdong
> > > Sent: Friday, October 23, 2015 8:35 PM
> > > To: David Henningsson; Yang, Libin; Raymond Yau; Takashi Iwai
> > > Cc: airlied@linux.ie; tanuk@iki.fi; ALSA Development Mailing List;
> > > Girdwood, Liam R
> > > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> > >
> > > > -----Original Message-----
> > > > From: David Henningsson
> [mailto:david.henningsson@canonical.com]
> > > > Sent: Friday, October 23, 2015 6:56 PM
> > > >
> > > > On 2015-10-23 07:30, Lin, Mengdong wrote:
> > > > >> -----Original Message-----
> > > > >> From: David Henningsson
> > > [mailto:david.henningsson@canonical.com]
> > > > >> Sent: Thursday, October 22, 2015 4:53 PM
> > > > >
> > > > > [snip]
> > > > >
> > > > >> I'll try to explain my suggestion (which I believe Takashi's
> buying
> > > > >> too) one more time then:
> > > > >>
> > > > >> First, when a monitor is plugged in, we need to dynamically
> assign
> > > > >> this monitor to five PCM devices. I believe this scheme will be
> best:
> > > > >>
> > > > >> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3.
> > > > >> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7.
> > > > >> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8.
> > > > >> For a monitor at dev index 1 (any pin), it will prefer PCM 9.
> > > > >> For a monitor at dev index 2 (any pin), it will prefer PCM 10.
> > > > >>
> > > > >> For monitors at dev indices > 2 (can that happen?), or if the
> PCM is
> > > > >> already assigned to something else, try PCMs in this order: 9,
> 10, 3,
> > > 7, 8.
> > > > >> (Subject to discussion perhaps, I don't think the order matters
> too
> > > > >> much, because conflicts will be rare in practice.)
> > > > >
> > > > > Hi David,
> > > > >
> > > > > Would you please clarify why PA needs such a fixed binding
> > > between PCM
> > > > 3,7, 8 and pin 0x05,6,7?
> > > >
> > > > PulseAudio saves information about profile and volume, and does
> so
> > > on
> > > > what in PA terminology is called a "port". PA binds this port to a
> > > specific Jack
> > > > kctl and a PCM device. How this fits together is configured in the
> files
> > > in
> > > > /usr/share/pulseaudio/alsa-mixer/ .
> > > >
> > > > E g, if both one HDMI and one DP monitor are both connected,
> the
> > > user
> > > > might set the volume (through PA) of the HDMI monitor to high
> and
> > > the DP
> > > > monitor to low. The user then reboots. Now, the PCM-to-
> monitor
> > > (and Jack
> > > > kctl-to-monitor) mapping needs to remain the same after a
> reboot,
> > > > otherwise PA might restore the volume to the wrong monitor.
> > >
> > > I see. Thank you for the info!
> > > Random binding can break static mapping since the order of hot-
> plug
> > > unsol events is out of our control.
> > >
> > > >
> > > > > And how will PA handle PCM 9,10 in a different way?
> > > >
> > > > PA will handle PCM 9 and 10 in the same way.
> > > >
> > > > > They are not bound to pins, and even not able to dev indexes.
> > > > > In practice, a platform will usually support either a DP port or a
> > > HDMI port
> > > > from the Intel integrated GPU for cost consideration.
> > > > > But theoretically i915 can use same device index on two
> different
> > > pins to
> > > > connect monitors, e.g. pin 0x05, dev index 2 for one monitor and
> pin
> > > 0x06,
> > > > dev index 2 for the other.
> > > >
> > > > In theory, there are certainly cases where the PCM device
> allocation
> > > can
> > > > cause problems for PA. What I'm trying to achieve is that these
> cases
> > > will be
> > > > so few that no one will ever notice.
> > >
> > > I agree. Your suggestion can keep static mapping between
> monitors
> > > and PCM devices during various display mode change and power
> cycle
> > > for common use cases.
> > >
> > > Regards
> > > Mengdong
> > >
> > > >
> > > > > On Intel platforms, the max dev indices is 2. Not sure about
> Nvidia
> > > and
> > > > AMD.
> > > >
> > > > Ok, thanks for the clarification.
> > > >
> > > > --
> > > > David Henningsson, Canonical Ltd.
> > > > https://launchpad.net/~diwic
> >

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Mon, 02 Nov 2015 08:30:19 +0100,
Yang, Libin wrote:
> 
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Friday, October 30, 2015 7:27 PM
> > To: Yang, Libin
> > Cc: Lin, Mengdong; David Henningsson; Raymond Yau; airlied@linux.ie;
> > tanuk@iki.fi; ALSA Development Mailing List; Girdwood, Liam R; Lu,
> > Han
> > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > 
> > On Tue, 27 Oct 2015 09:45:17 +0100,
> > Yang, Libin wrote:
> > >
> > > Hi Takashi and David,
> > >
> > > There are still some opens. Would you please help to comment?
> > >
> > > 1. SPDIF kctl.
> > > This SPDIF number will be the same as PCM and be bound to the PCM.
> > > The pin nid of SPDIF will not be initialized. And the pin nid will be
> > assigned
> > > After PCM is bound to the pin. (How to assign?)
> > 
> > I don't understand the question.  Could you elaborate?
> 
> In alsamixer for HDMI, we can see S/PDIF ctl to control 
> mute/unmute. Also in driver, we can see it creates the 
> ctls with snd_hda_create_dig_out_ctls() in build_controls() 
> based on pin number. I wonder whether user space use 
> these ctls based on pin or pcm? Suppose it should be also 
> based on PCM, right?

Right, these are for PCMs


Takashi

Re: DP1.2 MST audio support discussion

[David Henningsson]

On 2015-11-02 08:30, Yang, Libin wrote:
>
>>> 4. power management
>>> If we close the PCM when disconnecting monitor, the driver will
>> return
>>> -ENODEV, and we assume user space will close the PCM at once .
>> ... if we implement it.  Actually this behavior (returning -ENODEV) is
>> not mandatory and needs investigation beforehand, whether this
>> breaks
>> any applications, especially PA.
> Yes. I heard that PA has dummy PCM and when there is no HW to
> play the audio, PA can smoothly move the PCM from HW to dummy
> PCM. If it's true, stopping PCM will not break PA, I think.

Well, in most cases (not all) there will be an analog output available, 
so we're more likely to move there than to a dummy PCM. The problem is 
that PA does not currently figure out that a -ENODEV means that one 
should switch from a digital to an analog profile. So, at least at this 
point, don't expect a "smooth move".

I'm not sure if this is a good idea or not, but just brainstorming here:

If PA (or other application) tries to play back to a PCM, and that PCM 
is currently unassigned. What would happen if we actually assigned a 
converter node at that point, but no pin node connected to that 
converter node? Would that give a backwards compatible behaviour? I e, 
audio userspace could successfully play back audio through the converter 
node, but then the audio goes nowhere because there is no pin node assigned?

(Or perhaps we PA developers should actually start supporting this 
properly like we said that we should do, for like three years or 
something...)

// David

Re: DP1.2 MST audio support discussion

[Yang, Libin]

+ Jani, who is from Intel gfx team. 

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Monday, November 02, 2015 3:55 PM
> To: Yang, Libin; Takashi Iwai
> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> Development Mailing List; Girdwood, Liam R; Lu, Han
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> 
> 
> On 2015-11-02 08:30, Yang, Libin wrote:
> >
> >>> 4. power management
> >>> If we close the PCM when disconnecting monitor, the driver will
> >> return
> >>> -ENODEV, and we assume user space will close the PCM at once .
> >> ... if we implement it.  Actually this behavior (returning -ENODEV) is
> >> not mandatory and needs investigation beforehand, whether this
> >> breaks
> >> any applications, especially PA.
> > Yes. I heard that PA has dummy PCM and when there is no HW to
> > play the audio, PA can smoothly move the PCM from HW to dummy
> > PCM. If it's true, stopping PCM will not break PA, I think.
> 
> Well, in most cases (not all) there will be an analog output available,
> so we're more likely to move there than to a dummy PCM. The
> problem is
> that PA does not currently figure out that a -ENODEV means that one
> should switch from a digital to an analog profile. So, at least at this
> point, don't expect a "smooth move".
> 
> I'm not sure if this is a good idea or not, but just brainstorming here:
> 
> If PA (or other application) tries to play back to a PCM, and that PCM
> is currently unassigned. What would happen if we actually assigned a
> converter node at that point, but no pin node connected to that
> converter node? Would that give a backwards compatible behaviour? I
> e,
> audio userspace could successfully play back audio through the
> converter
> node, but then the audio goes nowhere because there is no pin node
> assigned?

GFX team hope us that if there is no monitor connected, audio
should release gfx so gfx driver can enter power save mode.
Based on the requirement, audio driver may need stop playback
as soon as the monitor is disconnected.

> 
> (Or perhaps we PA developers should actually start supporting this
> properly like we said that we should do, for like three years or
> something...)
> 
> // David

Re: DP1.2 MST audio support discussion

[Jani Nikula]

On Wed, 04 Nov 2015, "Yang, Libin" <libin.yang@intel.com> wrote:
> + Jani, who is from Intel gfx team. 
>
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Monday, November 02, 2015 3:55 PM
>> To: Yang, Libin; Takashi Iwai
>> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
>> Development Mailing List; Girdwood, Liam R; Lu, Han
>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
>> 
>> 
>> 
>> On 2015-11-02 08:30, Yang, Libin wrote:
>> >
>> >>> 4. power management
>> >>> If we close the PCM when disconnecting monitor, the driver will
>> >> return
>> >>> -ENODEV, and we assume user space will close the PCM at once .
>> >> ... if we implement it.  Actually this behavior (returning -ENODEV) is
>> >> not mandatory and needs investigation beforehand, whether this
>> >> breaks
>> >> any applications, especially PA.
>> > Yes. I heard that PA has dummy PCM and when there is no HW to
>> > play the audio, PA can smoothly move the PCM from HW to dummy
>> > PCM. If it's true, stopping PCM will not break PA, I think.
>> 
>> Well, in most cases (not all) there will be an analog output available,
>> so we're more likely to move there than to a dummy PCM. The
>> problem is
>> that PA does not currently figure out that a -ENODEV means that one
>> should switch from a digital to an analog profile. So, at least at this
>> point, don't expect a "smooth move".
>> 
>> I'm not sure if this is a good idea or not, but just brainstorming here:
>> 
>> If PA (or other application) tries to play back to a PCM, and that PCM
>> is currently unassigned. What would happen if we actually assigned a
>> converter node at that point, but no pin node connected to that
>> converter node? Would that give a backwards compatible behaviour? I
>> e,
>> audio userspace could successfully play back audio through the
>> converter
>> node, but then the audio goes nowhere because there is no pin node
>> assigned?
>
> GFX team hope us that if there is no monitor connected, audio
> should release gfx so gfx driver can enter power save mode.
> Based on the requirement, audio driver may need stop playback
> as soon as the monitor is disconnected.

Rather, as soon as the userspace responding to hotplug uevents has
reacted and disabled the display. See [1] for a better explanation. In
other words, it would be desirable that you call the put power hook in
response to intel_audio_codec_disable().

BR,
Jani.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=90447#c19

>
>> 
>> (Or perhaps we PA developers should actually start supporting this
>> properly like we said that we should do, for like three years or
>> something...)
>> 
>> // David
>

-- 
Jani Nikula, Intel Open Source Technology Center

Re: DP1.2 MST audio support discussion

[David Henningsson]

On 2015-11-04 15:17, Yang, Libin wrote:
> + Jani, who is from Intel gfx team.
>
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Monday, November 02, 2015 3:55 PM
>> To: Yang, Libin; Takashi Iwai
>> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
>> Development Mailing List; Girdwood, Liam R; Lu, Han
>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
>>
>>
>>
>> On 2015-11-02 08:30, Yang, Libin wrote:
>>>
>>>>> 4. power management
>>>>> If we close the PCM when disconnecting monitor, the driver will
>>>> return
>>>>> -ENODEV, and we assume user space will close the PCM at once .
>>>> ... if we implement it.  Actually this behavior (returning -ENODEV) is
>>>> not mandatory and needs investigation beforehand, whether this
>>>> breaks
>>>> any applications, especially PA.
>>> Yes. I heard that PA has dummy PCM and when there is no HW to
>>> play the audio, PA can smoothly move the PCM from HW to dummy
>>> PCM. If it's true, stopping PCM will not break PA, I think.
>>
>> Well, in most cases (not all) there will be an analog output available,
>> so we're more likely to move there than to a dummy PCM. The
>> problem is
>> that PA does not currently figure out that a -ENODEV means that one
>> should switch from a digital to an analog profile. So, at least at this
>> point, don't expect a "smooth move".
>>
>> I'm not sure if this is a good idea or not, but just brainstorming here:
>>
>> If PA (or other application) tries to play back to a PCM, and that PCM
>> is currently unassigned. What would happen if we actually assigned a
>> converter node at that point, but no pin node connected to that
>> converter node? Would that give a backwards compatible behaviour? I
>> e,
>> audio userspace could successfully play back audio through the
>> converter
>> node, but then the audio goes nowhere because there is no pin node
>> assigned?
>
> GFX team hope us that if there is no monitor connected, audio
> should release gfx so gfx driver can enter power save mode.
> Based on the requirement, audio driver may need stop playback
> as soon as the monitor is disconnected.

I'm not talking about continuous playback here, so power consumption 
should not be a big concern. E g, if it takes a second or so before PA 
reroutes audio somewhere else, it's not a big deal from a power save 
perspective.

So I'm asking my question again. What would happen (on Intel hardware), 
if you stream audio to a converter node on the audio codec, and there is 
no pin node connected to that converter node?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Raymond Yau]

>
> So I'm asking my question again. What would happen (on Intel hardware),
if you stream audio to a converter node on the audio codec, and there is no
pin node connected to that converter node?

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=d1f15e06b2af57228d11e33e06a172ff58f5bc1c

For alt analog playback device , it return EBUSY when DAC of HP is not
available (independent switch is OFF)

BTW, as pulseaudio does not support multi streaming (e.g. playing different
audio stream to HP and rear panel of desktop)

How can pulseaudio support displayport multi streaming ?

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi David,


> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Thursday, November 05, 2015 5:07 PM
> To: Yang, Libin; Takashi Iwai
> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> 
> 
> On 2015-11-04 15:17, Yang, Libin wrote:
> > + Jani, who is from Intel gfx team.
> >
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson@canonical.com]
> >> Sent: Monday, November 02, 2015 3:55 PM
> >> To: Yang, Libin; Takashi Iwai
> >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> >> Development Mailing List; Girdwood, Liam R; Lu, Han
> >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> >>
> >>
> >>
> >> On 2015-11-02 08:30, Yang, Libin wrote:
> >>>
> >>>>> 4. power management
> >>>>> If we close the PCM when disconnecting monitor, the driver will
> >>>> return
> >>>>> -ENODEV, and we assume user space will close the PCM at once .
> >>>> ... if we implement it.  Actually this behavior (returning -ENODEV) is
> >>>> not mandatory and needs investigation beforehand, whether this
> >>>> breaks
> >>>> any applications, especially PA.
> >>> Yes. I heard that PA has dummy PCM and when there is no HW to
> >>> play the audio, PA can smoothly move the PCM from HW to dummy
> >>> PCM. If it's true, stopping PCM will not break PA, I think.
> >>
> >> Well, in most cases (not all) there will be an analog output available,
> >> so we're more likely to move there than to a dummy PCM. The
> >> problem is
> >> that PA does not currently figure out that a -ENODEV means that one
> >> should switch from a digital to an analog profile. So, at least at this
> >> point, don't expect a "smooth move".
> >>
> >> I'm not sure if this is a good idea or not, but just brainstorming here:
> >>
> >> If PA (or other application) tries to play back to a PCM, and that PCM
> >> is currently unassigned. What would happen if we actually assigned a
> >> converter node at that point, but no pin node connected to that
> >> converter node? Would that give a backwards compatible behaviour?
> I
> >> e,
> >> audio userspace could successfully play back audio through the
> >> converter
> >> node, but then the audio goes nowhere because there is no pin node
> >> assigned?
> >
> > GFX team hope us that if there is no monitor connected, audio
> > should release gfx so gfx driver can enter power save mode.
> > Based on the requirement, audio driver may need stop playback
> > as soon as the monitor is disconnected.
> 
> I'm not talking about continuous playback here, so power consumption
> should not be a big concern. E g, if it takes a second or so before PA
> reroutes audio somewhere else, it's not a big deal from a power save
> perspective.
> 
> So I'm asking my question again. What would happen (on Intel hardware),
> if you stream audio to a converter node on the audio codec, and there is
> no pin node connected to that converter node?

I changed the audio driver and did the test today. The test is:
1. Pin 5 connect to converter 2 and playback, there is sound from pin 5.
2. Pin 5 connect to converter 2 (no other pin is connected to cvt2), no sound.
3. Pin 5 connect back to cvt 2, there is sound, playback is normal.

And in step 2, the playback is still ongoing but no sound is out from any pin.

> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[David Henningsson]

On 2015-11-10 07:46, Yang, Libin wrote:
> Hi David,
>
>
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Thursday, November 05, 2015 5:07 PM
>> To: Yang, Libin; Takashi Iwai
>> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
>> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
>> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
>>
>>
>>
>> So I'm asking my question again. What would happen (on Intel hardware),
>> if you stream audio to a converter node on the audio codec, and there is
>> no pin node connected to that converter node?
>
> I changed the audio driver and did the test today. The test is:
> 1. Pin 5 connect to converter 2 and playback, there is sound from pin 5.
> 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2), no sound.
> 3. Pin 5 connect back to cvt 2, there is sound, playback is normal.
>
> And in step 2, the playback is still ongoing but no sound is out from any pin.

Sounds good to me, thanks for testing. Is this workaround something we 
could utilize in order to not break userspace? (This is a question for 
both you and Takashi.)

What we'll end up is essentially three types of objects:

  * PCM device (5 devices, 3,7,8,9,10)
   - all five devices are allocated when the driver initializes
   - all kcontrols are always bound to the PCM device (jack kctl, eld 
kctl, iec958 kctls etc)

  * Monitor (pin + MST index)
   - dynamically bound to a PCM at monitor plug-in time, according to a 
scheme that maximises the possibility for a monitor to always end up at 
the same PCM (as specified in earlier emails)

  * Converter node (3 nodes for Intel hardware)
    - dynamically bound to a PCM at playback open time (regardless of 
whether the PCM has a monitor or not)
    - return -EBUSY in case there is no free converter node


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Yang, Libin]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Tuesday, November 10, 2015 3:45 PM
> To: Yang, Libin; Takashi Iwai
> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> 
> 
> On 2015-11-10 07:46, Yang, Libin wrote:
> > Hi David,
> >
> >
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson@canonical.com]
> >> Sent: Thursday, November 05, 2015 5:07 PM
> >> To: Yang, Libin; Takashi Iwai
> >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> >>
> >>
> >>
> >> So I'm asking my question again. What would happen (on Intel
> hardware),
> >> if you stream audio to a converter node on the audio codec, and there
> is
> >> no pin node connected to that converter node?
> >
> > I changed the audio driver and did the test today. The test is:
> > 1. Pin 5 connect to converter 2 and playback, there is sound from pin 5.
> > 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2), no
> sound.
> > 3. Pin 5 connect back to cvt 2, there is sound, playback is normal.
> >
> > And in step 2, the playback is still ongoing but no sound is out from any
> pin.
> 
> Sounds good to me, thanks for testing. Is this workaround something we
> could utilize in order to not break userspace? (This is a question for
> both you and Takashi.)
> 
> What we'll end up is essentially three types of objects:
> 
>   * PCM device (5 devices, 3,7,8,9,10)
>    - all five devices are allocated when the driver initializes

This should be for Intel platform, right? The actually number
should be:
pin number + device entry number - 1.
On intel platform, pin_num = 3, dev_num = 3, so it will be 5.

>    - all kcontrols are always bound to the PCM device (jack kctl, eld
> kctl, iec958 kctls etc)

Sure, I agree on it.

> 
>   * Monitor (pin + MST index)
>    - dynamically bound to a PCM at monitor plug-in time, according to a
> scheme that maximises the possibility for a monitor to always end up at
> the same PCM (as specified in earlier emails)
> 
>   * Converter node (3 nodes for Intel hardware)
>     - dynamically bound to a PCM at playback open time (regardless of
> whether the PCM has a monitor or not)

If so, we still need use converter on codec. This means we can't turn
off the power well in i915.

To save the power, i915 suggests that if no monitor is connected,
we should not use the HDMI codec. This means open a PCM with
no pin attached will fail. Disconnecting monitor when the corresponding
PCM is playback will trigger stop PCM.

To help move to the new method smoothly, I will add a flag.
User can decide whether to use the aggressive power saving
solution or not.

>     - return -EBUSY in case there is no free converter node

Regards,
Libin

> 
> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Yang, Libin]

> -----Original Message-----
> From: Yang, Libin
> Sent: Wednesday, November 11, 2015 10:04 AM
> To: David Henningsson; Takashi Iwai
> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> 
> 
> > -----Original Message-----
> > From: David Henningsson [mailto:david.henningsson@canonical.com]
> > Sent: Tuesday, November 10, 2015 3:45 PM
> > To: Yang, Libin; Takashi Iwai
> > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> >
> >
> >
> > On 2015-11-10 07:46, Yang, Libin wrote:
> > > Hi David,
> > >
> > >
> > >> -----Original Message-----
> > >> From: David Henningsson
> [mailto:david.henningsson@canonical.com]
> > >> Sent: Thursday, November 05, 2015 5:07 PM
> > >> To: Yang, Libin; Takashi Iwai
> > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> ALSA
> > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > >>
> > >>
> > >>
> > >> So I'm asking my question again. What would happen (on Intel
> > hardware),
> > >> if you stream audio to a converter node on the audio codec, and
> there
> > is
> > >> no pin node connected to that converter node?
> > >
> > > I changed the audio driver and did the test today. The test is:
> > > 1. Pin 5 connect to converter 2 and playback, there is sound from pin
> 5.
> > > 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2), no
> > sound.
> > > 3. Pin 5 connect back to cvt 2, there is sound, playback is normal.
> > >
> > > And in step 2, the playback is still ongoing but no sound is out from
> any
> > pin.
> >
> > Sounds good to me, thanks for testing. Is this workaround something
> we
> > could utilize in order to not break userspace? (This is a question for
> > both you and Takashi.)
> >
> > What we'll end up is essentially three types of objects:
> >
> >   * PCM device (5 devices, 3,7,8,9,10)
> >    - all five devices are allocated when the driver initializes
> 
> This should be for Intel platform, right? The actually number
> should be:
> pin number + device entry number - 1.
> On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
> 
> >    - all kcontrols are always bound to the PCM device (jack kctl, eld
> > kctl, iec958 kctls etc)
> 
> Sure, I agree on it.
> 
> >
> >   * Monitor (pin + MST index)
> >    - dynamically bound to a PCM at monitor plug-in time, according to a
> > scheme that maximises the possibility for a monitor to always end up at
> > the same PCM (as specified in earlier emails)
> >
> >   * Converter node (3 nodes for Intel hardware)
> >     - dynamically bound to a PCM at playback open time (regardless of
> > whether the PCM has a monitor or not)
> 
> If so, we still need use converter on codec. This means we can't turn
> off the power well in i915.
> 
> To save the power, i915 suggests that if no monitor is connected,
> we should not use the HDMI codec. This means open a PCM with
> no pin attached will fail. Disconnecting monitor when the corresponding
> PCM is playback will trigger stop PCM.
> 
> To help move to the new method smoothly, I will add a flag.
> User can decide whether to use the aggressive power saving
> solution or not.

In  hdmi_pcm_open(), it will judge whether pin_idx is valid, 
if not it will return -EINVAL. So for dynamic PCM assignment,
open will fail if no monitor is connected.

If we want to support open on PCM without monitor, many
code must be rewrited. And it seems open a PCM without
monitor is not a good behavior. As Raymond said in previous
email, For alt analog playback device , it return EBUSY when
DAC of HP is not available. I think for HDMI audio we can
have the aligned behavior? And -ENODEV may be better.

Regards,
Libin

> 
> >     - return -EBUSY in case there is no free converter node
> 
> Regards,
> Libin
> 
> >
> >
> > --
> > David Henningsson, Canonical Ltd.
> > https://launchpad.net/~diwic

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Wed, 11 Nov 2015 08:58:29 +0100,
Yang, Libin wrote:
> 
> 
> > -----Original Message-----
> > From: Yang, Libin
> > Sent: Wednesday, November 11, 2015 10:04 AM
> > To: David Henningsson; Takashi Iwai
> > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> > 
> > 
> > > -----Original Message-----
> > > From: David Henningsson [mailto:david.henningsson@canonical.com]
> > > Sent: Tuesday, November 10, 2015 3:45 PM
> > > To: Yang, Libin; Takashi Iwai
> > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > >
> > >
> > >
> > > On 2015-11-10 07:46, Yang, Libin wrote:
> > > > Hi David,
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: David Henningsson
> > [mailto:david.henningsson@canonical.com]
> > > >> Sent: Thursday, November 05, 2015 5:07 PM
> > > >> To: Yang, Libin; Takashi Iwai
> > > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> > ALSA
> > > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > >>
> > > >>
> > > >>
> > > >> So I'm asking my question again. What would happen (on Intel
> > > hardware),
> > > >> if you stream audio to a converter node on the audio codec, and
> > there
> > > is
> > > >> no pin node connected to that converter node?
> > > >
> > > > I changed the audio driver and did the test today. The test is:
> > > > 1. Pin 5 connect to converter 2 and playback, there is sound from pin
> > 5.
> > > > 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2), no
> > > sound.
> > > > 3. Pin 5 connect back to cvt 2, there is sound, playback is normal.
> > > >
> > > > And in step 2, the playback is still ongoing but no sound is out from
> > any
> > > pin.
> > >
> > > Sounds good to me, thanks for testing. Is this workaround something
> > we
> > > could utilize in order to not break userspace? (This is a question for
> > > both you and Takashi.)
> > >
> > > What we'll end up is essentially three types of objects:
> > >
> > >   * PCM device (5 devices, 3,7,8,9,10)
> > >    - all five devices are allocated when the driver initializes
> > 
> > This should be for Intel platform, right? The actually number
> > should be:
> > pin number + device entry number - 1.
> > On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
> > 
> > >    - all kcontrols are always bound to the PCM device (jack kctl, eld
> > > kctl, iec958 kctls etc)
> > 
> > Sure, I agree on it.
> > 
> > >
> > >   * Monitor (pin + MST index)
> > >    - dynamically bound to a PCM at monitor plug-in time, according to a
> > > scheme that maximises the possibility for a monitor to always end up at
> > > the same PCM (as specified in earlier emails)
> > >
> > >   * Converter node (3 nodes for Intel hardware)
> > >     - dynamically bound to a PCM at playback open time (regardless of
> > > whether the PCM has a monitor or not)
> > 
> > If so, we still need use converter on codec. This means we can't turn
> > off the power well in i915.
> > 
> > To save the power, i915 suggests that if no monitor is connected,
> > we should not use the HDMI codec. This means open a PCM with
> > no pin attached will fail. Disconnecting monitor when the corresponding
> > PCM is playback will trigger stop PCM.
> > 
> > To help move to the new method smoothly, I will add a flag.
> > User can decide whether to use the aggressive power saving
> > solution or not.
> 
> In  hdmi_pcm_open(), it will judge whether pin_idx is valid, 
> if not it will return -EINVAL. So for dynamic PCM assignment,
> open will fail if no monitor is connected.
> 
> If we want to support open on PCM without monitor, many
> code must be rewrited. And it seems open a PCM without
> monitor is not a good behavior. As Raymond said in previous
> email, For alt analog playback device , it return EBUSY when
> DAC of HP is not available. I think for HDMI audio we can
> have the aligned behavior? And -ENODEV may be better.

Libin, it's why I've been repeated asking to split the patches,
instead of posting a big iron patch.  Then we can test and evaluate
whether this part is really working in general.


Takashi

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Wednesday, November 11, 2015 4:06 PM
> To: Yang, Libin
> Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie';
> 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu,
> Han; Nikula, Jani
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> On Wed, 11 Nov 2015 08:58:29 +0100,
> Yang, Libin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Yang, Libin
> > > Sent: Wednesday, November 11, 2015 10:04 AM
> > > To: David Henningsson; Takashi Iwai
> > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> > >
> > >
> > > > -----Original Message-----
> > > > From: David Henningsson
> [mailto:david.henningsson@canonical.com]
> > > > Sent: Tuesday, November 10, 2015 3:45 PM
> > > > To: Yang, Libin; Takashi Iwai
> > > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> ALSA
> > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > >
> > > >
> > > >
> > > > On 2015-11-10 07:46, Yang, Libin wrote:
> > > > > Hi David,
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: David Henningsson
> > > [mailto:david.henningsson@canonical.com]
> > > > >> Sent: Thursday, November 05, 2015 5:07 PM
> > > > >> To: Yang, Libin; Takashi Iwai
> > > > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> > > ALSA
> > > > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
> Jani
> > > > >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > >>
> > > > >>
> > > > >>
> > > > >> So I'm asking my question again. What would happen (on Intel
> > > > hardware),
> > > > >> if you stream audio to a converter node on the audio codec, and
> > > there
> > > > is
> > > > >> no pin node connected to that converter node?
> > > > >
> > > > > I changed the audio driver and did the test today. The test is:
> > > > > 1. Pin 5 connect to converter 2 and playback, there is sound from
> pin
> > > 5.
> > > > > 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2),
> no
> > > > sound.
> > > > > 3. Pin 5 connect back to cvt 2, there is sound, playback is normal.
> > > > >
> > > > > And in step 2, the playback is still ongoing but no sound is out from
> > > any
> > > > pin.
> > > >
> > > > Sounds good to me, thanks for testing. Is this workaround
> something
> > > we
> > > > could utilize in order to not break userspace? (This is a question for
> > > > both you and Takashi.)
> > > >
> > > > What we'll end up is essentially three types of objects:
> > > >
> > > >   * PCM device (5 devices, 3,7,8,9,10)
> > > >    - all five devices are allocated when the driver initializes
> > >
> > > This should be for Intel platform, right? The actually number
> > > should be:
> > > pin number + device entry number - 1.
> > > On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
> > >
> > > >    - all kcontrols are always bound to the PCM device (jack kctl, eld
> > > > kctl, iec958 kctls etc)
> > >
> > > Sure, I agree on it.
> > >
> > > >
> > > >   * Monitor (pin + MST index)
> > > >    - dynamically bound to a PCM at monitor plug-in time, according
> to a
> > > > scheme that maximises the possibility for a monitor to always end
> up at
> > > > the same PCM (as specified in earlier emails)
> > > >
> > > >   * Converter node (3 nodes for Intel hardware)
> > > >     - dynamically bound to a PCM at playback open time (regardless
> of
> > > > whether the PCM has a monitor or not)
> > >
> > > If so, we still need use converter on codec. This means we can't turn
> > > off the power well in i915.
> > >
> > > To save the power, i915 suggests that if no monitor is connected,
> > > we should not use the HDMI codec. This means open a PCM with
> > > no pin attached will fail. Disconnecting monitor when the
> corresponding
> > > PCM is playback will trigger stop PCM.
> > >
> > > To help move to the new method smoothly, I will add a flag.
> > > User can decide whether to use the aggressive power saving
> > > solution or not.
> >
> > In  hdmi_pcm_open(), it will judge whether pin_idx is valid,
> > if not it will return -EINVAL. So for dynamic PCM assignment,
> > open will fail if no monitor is connected.
> >
> > If we want to support open on PCM without monitor, many
> > code must be rewrited. And it seems open a PCM without
> > monitor is not a good behavior. As Raymond said in previous
> > email, For alt analog playback device , it return EBUSY when
> > DAC of HP is not available. I think for HDMI audio we can
> > have the aligned behavior? And -ENODEV may be better.
> 
> Libin, it's why I've been repeated asking to split the patches,
> instead of posting a big iron patch.  Then we can test and evaluate
> whether this part is really working in general.

Yes, I understand. :) The patches are being split. Suppose these 2 days
patches should be ready for review.

Regards,
Libin

> 
> 
> Takashi

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Wed, 11 Nov 2015 09:11:49 +0100,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Wednesday, November 11, 2015 4:06 PM
> > To: Yang, Libin
> > Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie';
> > 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu,
> > Han; Nikula, Jani
> > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > 
> > On Wed, 11 Nov 2015 08:58:29 +0100,
> > Yang, Libin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Yang, Libin
> > > > Sent: Wednesday, November 11, 2015 10:04 AM
> > > > To: David Henningsson; Takashi Iwai
> > > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA
> > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: David Henningsson
> > [mailto:david.henningsson@canonical.com]
> > > > > Sent: Tuesday, November 10, 2015 3:45 PM
> > > > > To: Yang, Libin; Takashi Iwai
> > > > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> > ALSA
> > > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > >
> > > > >
> > > > >
> > > > > On 2015-11-10 07:46, Yang, Libin wrote:
> > > > > > Hi David,
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: David Henningsson
> > > > [mailto:david.henningsson@canonical.com]
> > > > > >> Sent: Thursday, November 05, 2015 5:07 PM
> > > > > >> To: Yang, Libin; Takashi Iwai
> > > > > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> > > > ALSA
> > > > > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
> > Jani
> > > > > >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> So I'm asking my question again. What would happen (on Intel
> > > > > hardware),
> > > > > >> if you stream audio to a converter node on the audio codec, and
> > > > there
> > > > > is
> > > > > >> no pin node connected to that converter node?
> > > > > >
> > > > > > I changed the audio driver and did the test today. The test is:
> > > > > > 1. Pin 5 connect to converter 2 and playback, there is sound from
> > pin
> > > > 5.
> > > > > > 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2),
> > no
> > > > > sound.
> > > > > > 3. Pin 5 connect back to cvt 2, there is sound, playback is normal.
> > > > > >
> > > > > > And in step 2, the playback is still ongoing but no sound is out from
> > > > any
> > > > > pin.
> > > > >
> > > > > Sounds good to me, thanks for testing. Is this workaround
> > something
> > > > we
> > > > > could utilize in order to not break userspace? (This is a question for
> > > > > both you and Takashi.)
> > > > >
> > > > > What we'll end up is essentially three types of objects:
> > > > >
> > > > >   * PCM device (5 devices, 3,7,8,9,10)
> > > > >    - all five devices are allocated when the driver initializes
> > > >
> > > > This should be for Intel platform, right? The actually number
> > > > should be:
> > > > pin number + device entry number - 1.
> > > > On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
> > > >
> > > > >    - all kcontrols are always bound to the PCM device (jack kctl, eld
> > > > > kctl, iec958 kctls etc)
> > > >
> > > > Sure, I agree on it.
> > > >
> > > > >
> > > > >   * Monitor (pin + MST index)
> > > > >    - dynamically bound to a PCM at monitor plug-in time, according
> > to a
> > > > > scheme that maximises the possibility for a monitor to always end
> > up at
> > > > > the same PCM (as specified in earlier emails)
> > > > >
> > > > >   * Converter node (3 nodes for Intel hardware)
> > > > >     - dynamically bound to a PCM at playback open time (regardless
> > of
> > > > > whether the PCM has a monitor or not)
> > > >
> > > > If so, we still need use converter on codec. This means we can't turn
> > > > off the power well in i915.
> > > >
> > > > To save the power, i915 suggests that if no monitor is connected,
> > > > we should not use the HDMI codec. This means open a PCM with
> > > > no pin attached will fail. Disconnecting monitor when the
> > corresponding
> > > > PCM is playback will trigger stop PCM.
> > > >
> > > > To help move to the new method smoothly, I will add a flag.
> > > > User can decide whether to use the aggressive power saving
> > > > solution or not.
> > >
> > > In  hdmi_pcm_open(), it will judge whether pin_idx is valid,
> > > if not it will return -EINVAL. So for dynamic PCM assignment,
> > > open will fail if no monitor is connected.
> > >
> > > If we want to support open on PCM without monitor, many
> > > code must be rewrited. And it seems open a PCM without
> > > monitor is not a good behavior. As Raymond said in previous
> > > email, For alt analog playback device , it return EBUSY when
> > > DAC of HP is not available. I think for HDMI audio we can
> > > have the aligned behavior? And -ENODEV may be better.
> > 
> > Libin, it's why I've been repeated asking to split the patches,
> > instead of posting a big iron patch.  Then we can test and evaluate
> > whether this part is really working in general.
> 
> Yes, I understand. :) The patches are being split. Suppose these 2 days
> patches should be ready for review.

Well, you don't have to post full patchset at all.  Rather in such a
case, a gradual test is preferred.  That is, cook this functionality
patch(es) quickly, and let people test it.  Once after it's confirmed,
start working on the rest.  It's not worth to wait for a week for each
respin because of the size and the features of of the whole patchset.


Takashi

Re: DP1.2 MST audio support discussion

[Yang, Libin]

Hi Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Wednesday, November 11, 2015 4:27 PM
> To: Yang, Libin
> Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie';
> 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu,
> Han; Nikula, Jani
> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> 
> On Wed, 11 Nov 2015 09:11:49 +0100,
> Yang, Libin wrote:
> >
> > Hi Takashi,
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > Sent: Wednesday, November 11, 2015 4:06 PM
> > > To: Yang, Libin
> > > Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau';
> 'airlied@linux.ie';
> > > 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu,
> > > Han; Nikula, Jani
> > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > >
> > > On Wed, 11 Nov 2015 08:58:29 +0100,
> > > Yang, Libin wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Yang, Libin
> > > > > Sent: Wednesday, November 11, 2015 10:04 AM
> > > > > To: David Henningsson; Takashi Iwai
> > > > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> ALSA
> > > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > > > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: David Henningsson
> > > [mailto:david.henningsson@canonical.com]
> > > > > > Sent: Tuesday, November 10, 2015 3:45 PM
> > > > > > To: Yang, Libin; Takashi Iwai
> > > > > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> > > ALSA
> > > > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
> Jani
> > > > > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 2015-11-10 07:46, Yang, Libin wrote:
> > > > > > > Hi David,
> > > > > > >
> > > > > > >
> > > > > > >> -----Original Message-----
> > > > > > >> From: David Henningsson
> > > > > [mailto:david.henningsson@canonical.com]
> > > > > > >> Sent: Thursday, November 05, 2015 5:07 PM
> > > > > > >> To: Yang, Libin; Takashi Iwai
> > > > > > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie;
> tanuk@iki.fi;
> > > > > ALSA
> > > > > > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
> > > Jani
> > > > > > >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> So I'm asking my question again. What would happen (on
> Intel
> > > > > > hardware),
> > > > > > >> if you stream audio to a converter node on the audio codec,
> and
> > > > > there
> > > > > > is
> > > > > > >> no pin node connected to that converter node?
> > > > > > >
> > > > > > > I changed the audio driver and did the test today. The test is:
> > > > > > > 1. Pin 5 connect to converter 2 and playback, there is sound
> from
> > > pin
> > > > > 5.
> > > > > > > 2. Pin 5 connect to converter 2 (no other pin is connected to
> cvt2),
> > > no
> > > > > > sound.
> > > > > > > 3. Pin 5 connect back to cvt 2, there is sound, playback is
> normal.
> > > > > > >
> > > > > > > And in step 2, the playback is still ongoing but no sound is out
> from
> > > > > any
> > > > > > pin.
> > > > > >
> > > > > > Sounds good to me, thanks for testing. Is this workaround
> > > something
> > > > > we
> > > > > > could utilize in order to not break userspace? (This is a question
> for
> > > > > > both you and Takashi.)
> > > > > >
> > > > > > What we'll end up is essentially three types of objects:
> > > > > >
> > > > > >   * PCM device (5 devices, 3,7,8,9,10)
> > > > > >    - all five devices are allocated when the driver initializes
> > > > >
> > > > > This should be for Intel platform, right? The actually number
> > > > > should be:
> > > > > pin number + device entry number - 1.
> > > > > On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
> > > > >
> > > > > >    - all kcontrols are always bound to the PCM device (jack kctl,
> eld
> > > > > > kctl, iec958 kctls etc)
> > > > >
> > > > > Sure, I agree on it.
> > > > >
> > > > > >
> > > > > >   * Monitor (pin + MST index)
> > > > > >    - dynamically bound to a PCM at monitor plug-in time,
> according
> > > to a
> > > > > > scheme that maximises the possibility for a monitor to always
> end
> > > up at
> > > > > > the same PCM (as specified in earlier emails)
> > > > > >
> > > > > >   * Converter node (3 nodes for Intel hardware)
> > > > > >     - dynamically bound to a PCM at playback open time
> (regardless
> > > of
> > > > > > whether the PCM has a monitor or not)
> > > > >
> > > > > If so, we still need use converter on codec. This means we can't
> turn
> > > > > off the power well in i915.
> > > > >
> > > > > To save the power, i915 suggests that if no monitor is connected,
> > > > > we should not use the HDMI codec. This means open a PCM with
> > > > > no pin attached will fail. Disconnecting monitor when the
> > > corresponding
> > > > > PCM is playback will trigger stop PCM.
> > > > >
> > > > > To help move to the new method smoothly, I will add a flag.
> > > > > User can decide whether to use the aggressive power saving
> > > > > solution or not.
> > > >
> > > > In  hdmi_pcm_open(), it will judge whether pin_idx is valid,
> > > > if not it will return -EINVAL. So for dynamic PCM assignment,
> > > > open will fail if no monitor is connected.
> > > >
> > > > If we want to support open on PCM without monitor, many
> > > > code must be rewrited. And it seems open a PCM without
> > > > monitor is not a good behavior. As Raymond said in previous
> > > > email, For alt analog playback device , it return EBUSY when
> > > > DAC of HP is not available. I think for HDMI audio we can
> > > > have the aligned behavior? And -ENODEV may be better.
> > >
> > > Libin, it's why I've been repeated asking to split the patches,
> > > instead of posting a big iron patch.  Then we can test and evaluate
> > > whether this part is really working in general.
> >
> > Yes, I understand. :) The patches are being split. Suppose these 2 days
> > patches should be ready for review.
> 
> Well, you don't have to post full patchset at all.  Rather in such a
> case, a gradual test is preferred.  That is, cook this functionality
> patch(es) quickly, and let people test it.  Once after it's confirmed,
> start working on the rest.  It's not worth to wait for a week for each
> respin because of the size and the features of of the whole patchset.

Get it. I will submit the patches if any is ready.

BTW: for the DP MST audio, can we put the patches into a new branch first
and wait all patches for MST audio are ready and mature, and then move 
the patches to master branch?

> 
> 
> Takashi

Re: DP1.2 MST audio support discussion

[Takashi Iwai]

On Wed, 11 Nov 2015 09:33:18 +0100,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Wednesday, November 11, 2015 4:27 PM
> > To: Yang, Libin
> > Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie';
> > 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu,
> > Han; Nikula, Jani
> > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > 
> > On Wed, 11 Nov 2015 09:11:49 +0100,
> > Yang, Libin wrote:
> > >
> > > Hi Takashi,
> > >
> > > > -----Original Message-----
> > > > From: Takashi Iwai [mailto:tiwai@suse.de]
> > > > Sent: Wednesday, November 11, 2015 4:06 PM
> > > > To: Yang, Libin
> > > > Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau';
> > 'airlied@linux.ie';
> > > > 'tanuk@iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu,
> > > > Han; Nikula, Jani
> > > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > >
> > > > On Wed, 11 Nov 2015 08:58:29 +0100,
> > > > Yang, Libin wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Yang, Libin
> > > > > > Sent: Wednesday, November 11, 2015 10:04 AM
> > > > > > To: David Henningsson; Takashi Iwai
> > > > > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> > ALSA
> > > > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > > > > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: David Henningsson
> > > > [mailto:david.henningsson@canonical.com]
> > > > > > > Sent: Tuesday, November 10, 2015 3:45 PM
> > > > > > > To: Yang, Libin; Takashi Iwai
> > > > > > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi;
> > > > ALSA
> > > > > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
> > Jani
> > > > > > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2015-11-10 07:46, Yang, Libin wrote:
> > > > > > > > Hi David,
> > > > > > > >
> > > > > > > >
> > > > > > > >> -----Original Message-----
> > > > > > > >> From: David Henningsson
> > > > > > [mailto:david.henningsson@canonical.com]
> > > > > > > >> Sent: Thursday, November 05, 2015 5:07 PM
> > > > > > > >> To: Yang, Libin; Takashi Iwai
> > > > > > > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie;
> > tanuk@iki.fi;
> > > > > > ALSA
> > > > > > > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
> > > > Jani
> > > > > > > >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> So I'm asking my question again. What would happen (on
> > Intel
> > > > > > > hardware),
> > > > > > > >> if you stream audio to a converter node on the audio codec,
> > and
> > > > > > there
> > > > > > > is
> > > > > > > >> no pin node connected to that converter node?
> > > > > > > >
> > > > > > > > I changed the audio driver and did the test today. The test is:
> > > > > > > > 1. Pin 5 connect to converter 2 and playback, there is sound
> > from
> > > > pin
> > > > > > 5.
> > > > > > > > 2. Pin 5 connect to converter 2 (no other pin is connected to
> > cvt2),
> > > > no
> > > > > > > sound.
> > > > > > > > 3. Pin 5 connect back to cvt 2, there is sound, playback is
> > normal.
> > > > > > > >
> > > > > > > > And in step 2, the playback is still ongoing but no sound is out
> > from
> > > > > > any
> > > > > > > pin.
> > > > > > >
> > > > > > > Sounds good to me, thanks for testing. Is this workaround
> > > > something
> > > > > > we
> > > > > > > could utilize in order to not break userspace? (This is a question
> > for
> > > > > > > both you and Takashi.)
> > > > > > >
> > > > > > > What we'll end up is essentially three types of objects:
> > > > > > >
> > > > > > >   * PCM device (5 devices, 3,7,8,9,10)
> > > > > > >    - all five devices are allocated when the driver initializes
> > > > > >
> > > > > > This should be for Intel platform, right? The actually number
> > > > > > should be:
> > > > > > pin number + device entry number - 1.
> > > > > > On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
> > > > > >
> > > > > > >    - all kcontrols are always bound to the PCM device (jack kctl,
> > eld
> > > > > > > kctl, iec958 kctls etc)
> > > > > >
> > > > > > Sure, I agree on it.
> > > > > >
> > > > > > >
> > > > > > >   * Monitor (pin + MST index)
> > > > > > >    - dynamically bound to a PCM at monitor plug-in time,
> > according
> > > > to a
> > > > > > > scheme that maximises the possibility for a monitor to always
> > end
> > > > up at
> > > > > > > the same PCM (as specified in earlier emails)
> > > > > > >
> > > > > > >   * Converter node (3 nodes for Intel hardware)
> > > > > > >     - dynamically bound to a PCM at playback open time
> > (regardless
> > > > of
> > > > > > > whether the PCM has a monitor or not)
> > > > > >
> > > > > > If so, we still need use converter on codec. This means we can't
> > turn
> > > > > > off the power well in i915.
> > > > > >
> > > > > > To save the power, i915 suggests that if no monitor is connected,
> > > > > > we should not use the HDMI codec. This means open a PCM with
> > > > > > no pin attached will fail. Disconnecting monitor when the
> > > > corresponding
> > > > > > PCM is playback will trigger stop PCM.
> > > > > >
> > > > > > To help move to the new method smoothly, I will add a flag.
> > > > > > User can decide whether to use the aggressive power saving
> > > > > > solution or not.
> > > > >
> > > > > In  hdmi_pcm_open(), it will judge whether pin_idx is valid,
> > > > > if not it will return -EINVAL. So for dynamic PCM assignment,
> > > > > open will fail if no monitor is connected.
> > > > >
> > > > > If we want to support open on PCM without monitor, many
> > > > > code must be rewrited. And it seems open a PCM without
> > > > > monitor is not a good behavior. As Raymond said in previous
> > > > > email, For alt analog playback device , it return EBUSY when
> > > > > DAC of HP is not available. I think for HDMI audio we can
> > > > > have the aligned behavior? And -ENODEV may be better.
> > > >
> > > > Libin, it's why I've been repeated asking to split the patches,
> > > > instead of posting a big iron patch.  Then we can test and evaluate
> > > > whether this part is really working in general.
> > >
> > > Yes, I understand. :) The patches are being split. Suppose these 2 days
> > > patches should be ready for review.
> > 
> > Well, you don't have to post full patchset at all.  Rather in such a
> > case, a gradual test is preferred.  That is, cook this functionality
> > patch(es) quickly, and let people test it.  Once after it's confirmed,
> > start working on the rest.  It's not worth to wait for a week for each
> > respin because of the size and the features of of the whole patchset.
> 
> Get it. I will submit the patches if any is ready.
> 
> BTW: for the DP MST audio, can we put the patches into a new branch first
> and wait all patches for MST audio are ready and mature, and then move 
> the patches to master branch?

On my tree?  It's fine, but it means that the patches aren't tested by
linux-next.  Or if you have your own git tree and it's published, you
can keep the changes there, instead.


Takashi

Re: DP1.2 MST audio support discussion

[Raymond Yau]

>>>>>
>>>>> 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
>>> 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 ?
>>
>>
>> For the jack name, what do you think if we change to
>> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
>
>
> Yes, it will impact PulseAudio. It will require changes to files in
>
>
http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths

Why do we use "hdmi" when MST is only supported by Display Port ?

https://bugs.freedesktop.org/show_bug.cgi?id=72795#c56

It seem the graphic driver use different name for HDMI and DP

DP1-1 , DP1-2 and DP1-3 , HDMI1

Re: DP1.2 MST audio support discussion

[Lin, Mengdong]

> -----Original Message-----
>From: Raymond Yau [mailto:superquad.vortex2@gmail.com] 
>Sent: Friday, October 23, 2015 5:40 PM

>>> For the jack name, what do you think if we change to
>>> "HDMI/DP, pin=n, dev=m" format? Will it impact on pulseaudio?
>>
>>
>>Yes, it will impact PulseAudio. It will require changes to files in
>>
>> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths
>Why do we use "hdmi" when MST is only supported by Display Port ?
>https://bugs.freedesktop.org/show_bug.cgi?id=72795#c56
>It seem the graphic driver use different name for HDMI and DP
>DP1-1 , DP1-2 and DP1-3 , HDMI1

Maybe I cannot give the best answer.

I feel there can be two reasons:
- HDMI came to the market earlier than DP. So the name "hdmi" is used at first.
- For GFX, the difference between HDMI and DP processing sequence is big. 
  But for audio, there is little difference. In audio driver, DP and HDMI pins are handled in the same way, probably the only difference is the audio infoframe format.
  And this reflects the HW: audio codec is only a GPU interface to feed audio data to its display pipelines. And GPU mixes the audio and video and translate the stream to different formats for HDMI and DP. 

Thanks
Mengdong

Re: DP1.2 MST audio support discussion

[Yang, Libin]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

Please check the attachment for details.

Regards,
Libin


> -----Original Message-----
> From: Yang, Libin
> Sent: Tuesday, October 13, 2015 2:26 PM
> To: 'Takashi Iwai'; Lin, Mengdong; tanuk@iki.fi; David Henningsson;
> Girdwood, Liam R
> Cc: alsa-devel@alsa-project.org; airlied@linux.ie
> Subject: DP1.2 MST audio support discussion
> 
> Hi Takashi and all,
> 
> We are planning to enable DP1.2 MST (Multi-Stream Transport)
> audio.
> 
> Based on the previous discussion, we will extend the
> struct hdmi_spec_per_pin to support MST audio device entry.
> So the struct hdmi_spec_per_pin can be a real pin or a device
> entry in the pin.  The idea is to add a member dev_idx in the
> struct hdmi_spec_per_pin. Dev_idx, together with pin_nid,
> can represent a device entry.
> 
> 1. Dynamic PCM assignment
> We will use dynamic PCM assignment for MST audio. This
> means we will create a fixed number of PCMs (the number
> is the same convertor number). All the created PCMs will not
> be assigned to any pin (device entry). When there is a monitor
> connected, an available PCM will be assigned to the pin. And
> it will be de-assigned when the monitor is disconnected.
> Userspace can fetch the HW param when monitor connection
> status is changed.
> 
> I'm not sure how to notify the userspace, such as notifying
> pulseaudio the PCM is assigned or de-assigned. Any ideas?
> 
> 2. Compatibility.
> We will patch patch_hdmi.c to support the MST audio.
> Will we use mst audio driver to support the old mode
> or we use a flag, when HW doesn't support MST audio,
> we will use the old code? Suppose MST audio driver should
> be able support both MST audio and non-MST audio.
> 
> 
> Regards,
> Libin
> 


[-- Attachment #2: Add Support for DP MST Audio to HD-Audio Driver.pdf --]
[-- Type: application/pdf, Size: 731123 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]