[Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
From: Dave Airlie
Add new verbs GET_DP_STREAM_ID and SET_DP_STREAM_ID from Intel docs.
get stream id and print in proc
split ELD to be per device not per pin
handle pd/eldv per device not per pin
setup codec->dp_mst earlier.
Signed-off-by: Dave Airlie
---
include/sound/hda_verbs.h | 2 +
sound/pci/hda/hda_codec.c | 1 +
sound/pci/hda/hda_proc.c | 5 +-
sound/pci/hda/patch_hdmi.c | 181 +++--
4 files changed, 131 insertions(+), 58 deletions(-)
diff --git a/include/sound/hda_verbs.h b/include/sound/hda_verbs.h
index d0509db..3b62ac5 100644
--- a/include/sound/hda_verbs.h
+++ b/include/sound/hda_verbs.h
@@ -75,6 +75,7 @@ enum {
#define AC_VERB_GET_HDMI_CHAN_SLOT 0x0f34
#define AC_VERB_GET_DEVICE_SEL 0xf35
#define AC_VERB_GET_DEVICE_LIST0xf36
+#define AC_VERB_GET_DP_STREAM_ID 0xf3c
/*
* SET verbs
@@ -115,6 +116,7 @@ enum {
#define AC_VERB_SET_HDMI_CP_CTRL 0x733
#define AC_VERB_SET_HDMI_CHAN_SLOT 0x734
#define AC_VERB_SET_DEVICE_SEL 0x735
+#define AC_VERB_SET_DP_STREAM_ID 0x73C
/*
* Parameter IDs
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 5645481..3981c63 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -482,6 +482,7 @@ int snd_hda_get_devices(struct hda_codec *codec, hda_nid_t
nid,
}
return devices;
}
+EXPORT_SYMBOL_GPL(snd_hda_get_devices);
/*
* destructor
diff --git a/sound/pci/hda/hda_proc.c b/sound/pci/hda/hda_proc.c
index baaf7ed0..39fac53 100644
--- a/sound/pci/hda/hda_proc.c
+++ b/sound/pci/hda/hda_proc.c
@@ -644,10 +644,13 @@ static void print_device_list(struct snd_info_buffer
*buffer,
int i, curr = -1;
u8 dev_list[AC_MAX_DEV_LIST_LEN];
int devlist_len;
+ int dp_s_id;
+ dp_s_id = snd_hda_codec_read(codec, nid, 0,
+ AC_VERB_GET_DP_STREAM_ID, 0);
devlist_len = snd_hda_get_devices(codec, nid, dev_list,
AC_MAX_DEV_LIST_LEN);
- snd_iprintf(buffer, " Devices: %d\n", devlist_len);
+ snd_iprintf(buffer, " Devices: %d: 0x%x\n", devlist_len, dp_s_id);
if (devlist_len <= 0)
return;
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 5f44f60..8272656 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -68,6 +68,17 @@ struct hdmi_spec_per_cvt {
/* max. connections to a widget */
#define HDA_MAX_CONNECTIONS32
+struct hdmi_spec_per_pin;
+#define HDA_MAX_DEVICES 3
+struct hdmi_spec_per_device {
+ struct hdmi_spec_per_pin *pin;
+ int device_idx;
+ struct hdmi_eld sink_eld;
+#ifdef CONFIG_PROC_FS
+ struct snd_info_entry *proc_entry;
+#endif
+};
+
struct hdmi_spec_per_pin {
hda_nid_t pin_nid;
int num_mux_nids;
@@ -76,7 +87,11 @@ struct hdmi_spec_per_pin {
hda_nid_t cvt_nid;
struct hda_codec *codec;
- struct hdmi_eld sink_eld;
+
+ int num_devices;
+ u8 dev_list[AC_MAX_DEV_LIST_LEN];
+ struct hdmi_spec_per_device devices[HDA_MAX_DEVICES];
+
struct mutex lock;
struct delayed_work work;
struct snd_kcontrol *eld_ctl;
@@ -86,9 +101,6 @@ struct hdmi_spec_per_pin {
bool non_pcm;
bool chmap_set; /* channel-map override by ALSA API? */
unsigned char chmap[8]; /* ALSA API channel-map */
-#ifdef CONFIG_PROC_FS
- struct snd_info_entry *proc_entry;
-#endif
};
struct cea_channel_speaker_allocation;
@@ -409,7 +421,7 @@ static int hdmi_eld_ctl_info(struct snd_kcontrol *kcontrol,
pin_idx = kcontrol->private_value;
per_pin = get_pin(spec, pin_idx);
- eld = &per_pin->sink_eld;
+ eld = &per_pin->devices[0].sink_eld;
mutex_lock(&per_pin->lock);
uinfo->count = eld->eld_valid ? eld->eld_size : 0;
@@ -429,7 +441,7 @@ static int hdmi_eld_ctl_get(struct snd_kcontrol *kcontrol,
pin_idx = kcontrol->private_value;
per_pin = get_pin(spec, pin_idx);
- eld = &per_pin->sink_eld;
+ eld = &per_pin->devices[0].sink_eld;
mutex_lock(&per_pin->lock);
if (eld->eld_size > ARRAY_SIZE(ucontrol->value.bytes.data)) {
@@ -549,60 +561,63 @@ static void hdmi_set_channel_count(struct hda_codec
*codec,
*/
#ifdef CONFIG_PROC_FS
-static void print_eld_info(struct snd_info_entry *entry,
- struct snd_info_buffer *buffer)
+static void print_eld_info_device(struct snd_info_entry *entry,
+ struct snd_info_buffer *buffer)
{
- struct hdmi_spec_per_pin *per_pin = entry->private_data;
+ struct hdmi_spec_per_device *per_device = entry->private_data;
- mutex_lock(&per_pin->lock);
- snd_hdmi_print_eld_info(&per_pin->sink_eld, buffer);
- mutex_unlock(&per_pin->lock);
+
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Fri, Jun 19, 2015 at 01:15:57PM +0200, Takashi Iwai wrote: > At Fri, 19 Jun 2015 20:33:39 +1000, > Dave Airlie wrote: > > > > On 19 June 2015 at 19:54, Lin, Mengdong wrote: > > > Hi Takashi/Dave, > > > > > > Shall we move or cc this discussion on audio driver side to ALSA ML? > > > > Oops I thought I had cc'ed these patches to alsa-devel as well when I sent > > them. > > > > > I think we also need to decide how to manage PCM devices for DP MST. > > > Now the HD-A driver create a PCM device for each pin, and the substream > > > number is 1 for each PCM. Now with DP MST enabled, each pin can support > > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL). > > > > > > There may be 2 options: > > > -#1: Let an HDMI codec specify number of substreams, same as the number > > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other > > > vendors can also specify a value according to actual HW capabilities. > > > > > > So for HSW, we have 3x3 subtreams totally. But we only have 3 convertors > > > (for 3 display pipelines), so we can open up to 3 substreams at the same > > > time. When the audio driver finds all 3 convertors are used when opening > > > a new substream, it will fail. > > > > One thing I noticed is the number of devices on a PIN is only updated when > > the MST device is plugged in so normally pins 5,6,7 have 0 devices, and when > > I plug in MST device, I get the 3 devices on port 6. So it seems dynamic > > enough at this point, though I guess it'll always be 0 or 3. > > > > > > - #2: Create PCM device dynamically. Only create a PCM devices for a > > > device > > > entry which connects to monitor with audio support. When the monitor > > > is removed, the PCM device will be disconnected, closed and removed, > > > similar to the USB case. > > > > > > This will change ALSA core. But there will be less PCM devices and > > > substreams, since the number of connected monitors Is decided by the > > > actual GPU display pipeline. > > > > I like this option more, since I think it should be more like USB, but I've > > no idea how much work it would be from the alsa side, this patch was > > probably as deep into alsa as I've gone. > > Two things have to be considered for compatibility: > - ELD, channel map and jack detection: these are created per PCM > device, and extending to substream would confuse user space a lot. > In theory, it can be extended using subdevice number, but in anyway > this won't work with PulseAudio as is. > > - The per-pin assignment provides a more or less persistent route to a > certain device. Changing the assignment method may break the > previous setup. > > Also, the dynamic PCM creation / removal is an issue that has been > discussed many times. Unfortunately it won't work as is, at lest for > PA. Currently PA does probing of devices only at the card probe time. > The hotplug of USB-audio works because it's always tied with the > card. But in this case, the card remains while only the PCM devices > will be created / removed, thus the probe in PA won't be triggered. I guess that means we either have to hotplug entire (fake) cards or fix up userspace to support mst audio properly? We had to do some minimal changes to the ddx drivers too to make sure they're rescanning the connector list properly. Imo since this is all new I think we could require PA to rescan the PCM dev list on hotplug events too to support DP MST. And we kinda do need hotplug at that level since if we'd hotplug the entire card we'd kill a stream that's running on some other display. And always registering all of them feels like a very bad hack too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
At Mon, 22 Jun 2015 14:54:29 +0200, Daniel Vetter wrote: > > On Fri, Jun 19, 2015 at 01:15:57PM +0200, Takashi Iwai wrote: > > At Fri, 19 Jun 2015 20:33:39 +1000, > > Dave Airlie wrote: > > > > > > On 19 June 2015 at 19:54, Lin, Mengdong wrote: > > > > Hi Takashi/Dave, > > > > > > > > Shall we move or cc this discussion on audio driver side to ALSA ML? > > > > > > Oops I thought I had cc'ed these patches to alsa-devel as well when I > > > sent them. > > > > > > > I think we also need to decide how to manage PCM devices for DP MST. > > > > Now the HD-A driver create a PCM device for each pin, and the substream > > > > number is 1 for each PCM. Now with DP MST enabled, each pin can support > > > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL). > > > > > > > > There may be 2 options: > > > > -#1: Let an HDMI codec specify number of substreams, same as the number > > > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other > > > > vendors can also specify a value according to actual HW capabilities. > > > > > > > > So for HSW, we have 3x3 subtreams totally. But we only have 3 convertors > > > > (for 3 display pipelines), so we can open up to 3 substreams at the same > > > > time. When the audio driver finds all 3 convertors are used when opening > > > > a new substream, it will fail. > > > > > > One thing I noticed is the number of devices on a PIN is only updated when > > > the MST device is plugged in so normally pins 5,6,7 have 0 devices, and > > > when > > > I plug in MST device, I get the 3 devices on port 6. So it seems dynamic > > > enough at this point, though I guess it'll always be 0 or 3. > > > > > > > > - #2: Create PCM device dynamically. Only create a PCM devices for a > > > > device > > > > entry which connects to monitor with audio support. When the monitor > > > > is removed, the PCM device will be disconnected, closed and removed, > > > > similar to the USB case. > > > > > > > > This will change ALSA core. But there will be less PCM devices and > > > > substreams, since the number of connected monitors Is decided by the > > > > actual GPU display pipeline. > > > > > > I like this option more, since I think it should be more like USB, but > > > I've > > > no idea how much work it would be from the alsa side, this patch was > > > probably as deep into alsa as I've gone. > > > > Two things have to be considered for compatibility: > > - ELD, channel map and jack detection: these are created per PCM > > device, and extending to substream would confuse user space a lot. > > In theory, it can be extended using subdevice number, but in anyway > > this won't work with PulseAudio as is. > > > > - The per-pin assignment provides a more or less persistent route to a > > certain device. Changing the assignment method may break the > > previous setup. > > > > Also, the dynamic PCM creation / removal is an issue that has been > > discussed many times. Unfortunately it won't work as is, at lest for > > PA. Currently PA does probing of devices only at the card probe time. > > The hotplug of USB-audio works because it's always tied with the > > card. But in this case, the card remains while only the PCM devices > > will be created / removed, thus the probe in PA won't be triggered. > > I guess that means we either have to hotplug entire (fake) cards or fix up > userspace to support mst audio properly? It would work for HSW/BDW. But BYT/BSW and SKL share the same controller for both HDMI and analog codecs, thus the card can't be handled as hotplugged. > We had to do some minimal changes > to the ddx drivers too to make sure they're rescanning the connector list > properly. Imo since this is all new I think we could require PA to rescan > the PCM dev list on hotplug events too to support DP MST. And we kinda do > need hotplug at that level since if we'd hotplug the entire card we'd kill > a stream that's running on some other display. > > And always registering all of them feels like a very bad hack too. Yeah, I personally am for the PCM hotplug, too. It's a cleaner way. (The current static assignment comes from the chips where they had no ELD communication -- the hardware before the recent onboard Intel and AMD gfx but connected somehow externally. For such hardware, we still need the static assignment.) OTOH, we have to keep some compatibility. And moving to the hotplug would break certainly some existing configuration that assumes the static port / device assignment. So, a compromise would be: - change the behavior via either Kconfig or module option. - create many PCM devices statically as much as possible The latter can be a problem in the case of AMD or Nvidia where 8 (or more?) ports may exist. The former is, of course, messy and confusing for users, too. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Mon, 2015-06-22 at 15:23 +0200, Takashi Iwai wrote: > At Mon, 22 Jun 2015 14:54:29 +0200, > Daniel Vetter wrote: > > > > On Fri, Jun 19, 2015 at 01:15:57PM +0200, Takashi Iwai wrote: > > > At Fri, 19 Jun 2015 20:33:39 +1000, > > > Dave Airlie wrote: > > > > > > > > On 19 June 2015 at 19:54, Lin, Mengdong wrote: > > > > > Hi Takashi/Dave, > > > > > > > > > > Shall we move or cc this discussion on audio driver side to ALSA ML? > > > > > > > > Oops I thought I had cc'ed these patches to alsa-devel as well when I > > > > sent them. > > > > > > > > > I think we also need to decide how to manage PCM devices for DP MST. > > > > > Now the HD-A driver create a PCM device for each pin, and the > > > > > substream > > > > > number is 1 for each PCM. Now with DP MST enabled, each pin can > > > > > support > > > > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL). > > > > > > > > > > There may be 2 options: > > > > > -#1: Let an HDMI codec specify number of substreams, same as the > > > > > number > > > > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other > > > > > vendors can also specify a value according to actual HW capabilities. > > > > > > > > > > So for HSW, we have 3x3 subtreams totally. But we only have 3 > > > > > convertors > > > > > (for 3 display pipelines), so we can open up to 3 substreams at the > > > > > same > > > > > time. When the audio driver finds all 3 convertors are used when > > > > > opening > > > > > a new substream, it will fail. > > > > > > > > One thing I noticed is the number of devices on a PIN is only updated > > > > when > > > > the MST device is plugged in so normally pins 5,6,7 have 0 devices, and > > > > when > > > > I plug in MST device, I get the 3 devices on port 6. So it seems dynamic > > > > enough at this point, though I guess it'll always be 0 or 3. > > > > > > > > > > - #2: Create PCM device dynamically. Only create a PCM devices for a > > > > > device > > > > > entry which connects to monitor with audio support. When the monitor > > > > > is removed, the PCM device will be disconnected, closed and removed, > > > > > similar to the USB case. > > > > > > > > > > This will change ALSA core. But there will be less PCM devices and > > > > > substreams, since the number of connected monitors Is decided by the > > > > > actual GPU display pipeline. > > > > > > > > I like this option more, since I think it should be more like USB, but > > > > I've > > > > no idea how much work it would be from the alsa side, this patch was > > > > probably as deep into alsa as I've gone. > > > > > > Two things have to be considered for compatibility: > > > - ELD, channel map and jack detection: these are created per PCM > > > device, and extending to substream would confuse user space a lot. > > > In theory, it can be extended using subdevice number, but in anyway > > > this won't work with PulseAudio as is. > > > > > > - The per-pin assignment provides a more or less persistent route to a > > > certain device. Changing the assignment method may break the > > > previous setup. > > > > > > Also, the dynamic PCM creation / removal is an issue that has been > > > discussed many times. Unfortunately it won't work as is, at lest for > > > PA. Currently PA does probing of devices only at the card probe time. > > > The hotplug of USB-audio works because it's always tied with the > > > card. But in this case, the card remains while only the PCM devices > > > will be created / removed, thus the probe in PA won't be triggered. > > > > I guess that means we either have to hotplug entire (fake) cards or fix up > > userspace to support mst audio properly? > > It would work for HSW/BDW. But BYT/BSW and SKL share the same > controller for both HDMI and analog codecs, thus the card can't be > handled as hotplugged. > > > We had to do some minimal changes > > to the ddx drivers too to make sure they're rescanning the connector list > > properly. Imo since this is all new I think we could require PA to rescan > > the PCM dev list on hotplug events too to support DP MST. And we kinda do > > need hotplug at that level since if we'd hotplug the entire card we'd kill > > a stream that's running on some other display. > > > > And always registering all of them feels like a very bad hack too. > > Yeah, I personally am for the PCM hotplug, too. It's a cleaner way. > > (The current static assignment comes from the chips where they had no > ELD communication -- the hardware before the recent onboard Intel and > AMD gfx but connected somehow externally. For such hardware, we > still need the static assignment.) > > OTOH, we have to keep some compatibility. And moving to the hotplug > would break certainly some existing configuration that assumes the > static port / device assignment. > > So, a compromise would be: > - change the behavior via either Kconfig or module option. > - create many PCM devices statically as much as possible > > The latter can be a
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote: > On Mon, 2015-06-22 at 15:23 +0200, Takashi Iwai wrote: > > At Mon, 22 Jun 2015 14:54:29 +0200, > > Daniel Vetter wrote: > > > > > > On Fri, Jun 19, 2015 at 01:15:57PM +0200, Takashi Iwai wrote: > > > > At Fri, 19 Jun 2015 20:33:39 +1000, > > > > Dave Airlie wrote: > > > > > > > > > > On 19 June 2015 at 19:54, Lin, Mengdong > > > > > wrote: > > > > > > Hi Takashi/Dave, > > > > > > > > > > > > Shall we move or cc this discussion on audio driver side to ALSA ML? > > > > > > > > > > Oops I thought I had cc'ed these patches to alsa-devel as well when I > > > > > sent them. > > > > > > > > > > > I think we also need to decide how to manage PCM devices for DP MST. > > > > > > Now the HD-A driver create a PCM device for each pin, and the > > > > > > substream > > > > > > number is 1 for each PCM. Now with DP MST enabled, each pin can > > > > > > support > > > > > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL). > > > > > > > > > > > > There may be 2 options: > > > > > > -#1: Let an HDMI codec specify number of substreams, same as the > > > > > > number > > > > > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other > > > > > > vendors can also specify a value according to actual HW > > > > > > capabilities. > > > > > > > > > > > > So for HSW, we have 3x3 subtreams totally. But we only have 3 > > > > > > convertors > > > > > > (for 3 display pipelines), so we can open up to 3 substreams at the > > > > > > same > > > > > > time. When the audio driver finds all 3 convertors are used when > > > > > > opening > > > > > > a new substream, it will fail. > > > > > > > > > > One thing I noticed is the number of devices on a PIN is only updated > > > > > when > > > > > the MST device is plugged in so normally pins 5,6,7 have 0 devices, > > > > > and when > > > > > I plug in MST device, I get the 3 devices on port 6. So it seems > > > > > dynamic > > > > > enough at this point, though I guess it'll always be 0 or 3. > > > > > > > > > > > > - #2: Create PCM device dynamically. Only create a PCM devices for > > > > > > a device > > > > > > entry which connects to monitor with audio support. When the monitor > > > > > > is removed, the PCM device will be disconnected, closed and removed, > > > > > > similar to the USB case. > > > > > > > > > > > > This will change ALSA core. But there will be less PCM devices and > > > > > > substreams, since the number of connected monitors Is decided by the > > > > > > actual GPU display pipeline. > > > > > > > > > > I like this option more, since I think it should be more like USB, > > > > > but I've > > > > > no idea how much work it would be from the alsa side, this patch was > > > > > probably as deep into alsa as I've gone. > > > > > > > > Two things have to be considered for compatibility: > > > > - ELD, channel map and jack detection: these are created per PCM > > > > device, and extending to substream would confuse user space a lot. > > > > In theory, it can be extended using subdevice number, but in anyway > > > > this won't work with PulseAudio as is. > > > > > > > > - The per-pin assignment provides a more or less persistent route to a > > > > certain device. Changing the assignment method may break the > > > > previous setup. > > > > > > > > Also, the dynamic PCM creation / removal is an issue that has been > > > > discussed many times. Unfortunately it won't work as is, at lest for > > > > PA. Currently PA does probing of devices only at the card probe time. > > > > The hotplug of USB-audio works because it's always tied with the > > > > card. But in this case, the card remains while only the PCM devices > > > > will be created / removed, thus the probe in PA won't be triggered. > > > > > > I guess that means we either have to hotplug entire (fake) cards or fix up > > > userspace to support mst audio properly? > > > > It would work for HSW/BDW. But BYT/BSW and SKL share the same > > controller for both HDMI and analog codecs, thus the card can't be > > handled as hotplugged. > > > > > We had to do some minimal changes > > > to the ddx drivers too to make sure they're rescanning the connector list > > > properly. Imo since this is all new I think we could require PA to rescan > > > the PCM dev list on hotplug events too to support DP MST. And we kinda do > > > need hotplug at that level since if we'd hotplug the entire card we'd kill > > > a stream that's running on some other display. > > > > > > And always registering all of them feels like a very bad hack too. > > > > Yeah, I personally am for the PCM hotplug, too. It's a cleaner way. > > > > (The current static assignment comes from the chips where they had no > > ELD communication -- the hardware before the recent onboard Intel and > > AMD gfx but connected somehow externally. For such hardware, we > > still need the static assignment.) > > > > OTOH, we have to keep some compatibility. And moving to t
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
At Mon, 22 Jun 2015 15:21:16 +, Kaskinen, Tanu wrote: > > On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote: > > On Mon, 2015-06-22 at 15:23 +0200, Takashi Iwai wrote: > > > At Mon, 22 Jun 2015 14:54:29 +0200, > > > Daniel Vetter wrote: > > > > > > > > On Fri, Jun 19, 2015 at 01:15:57PM +0200, Takashi Iwai wrote: > > > > > At Fri, 19 Jun 2015 20:33:39 +1000, > > > > > Dave Airlie wrote: > > > > > > > > > > > > On 19 June 2015 at 19:54, Lin, Mengdong > > > > > > wrote: > > > > > > > Hi Takashi/Dave, > > > > > > > > > > > > > > Shall we move or cc this discussion on audio driver side to ALSA > > > > > > > ML? > > > > > > > > > > > > Oops I thought I had cc'ed these patches to alsa-devel as well when > > > > > > I sent them. > > > > > > > > > > > > > I think we also need to decide how to manage PCM devices for DP > > > > > > > MST. > > > > > > > Now the HD-A driver create a PCM device for each pin, and the > > > > > > > substream > > > > > > > number is 1 for each PCM. Now with DP MST enabled, each pin can > > > > > > > support > > > > > > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL). > > > > > > > > > > > > > > There may be 2 options: > > > > > > > -#1: Let an HDMI codec specify number of substreams, same as the > > > > > > > number > > > > > > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. > > > > > > > Other > > > > > > > vendors can also specify a value according to actual HW > > > > > > > capabilities. > > > > > > > > > > > > > > So for HSW, we have 3x3 subtreams totally. But we only have 3 > > > > > > > convertors > > > > > > > (for 3 display pipelines), so we can open up to 3 substreams at > > > > > > > the same > > > > > > > time. When the audio driver finds all 3 convertors are used when > > > > > > > opening > > > > > > > a new substream, it will fail. > > > > > > > > > > > > One thing I noticed is the number of devices on a PIN is only > > > > > > updated when > > > > > > the MST device is plugged in so normally pins 5,6,7 have 0 devices, > > > > > > and when > > > > > > I plug in MST device, I get the 3 devices on port 6. So it seems > > > > > > dynamic > > > > > > enough at this point, though I guess it'll always be 0 or 3. > > > > > > > > > > > > > > - #2: Create PCM device dynamically. Only create a PCM devices > > > > > > > for a device > > > > > > > entry which connects to monitor with audio support. When the > > > > > > > monitor > > > > > > > is removed, the PCM device will be disconnected, closed and > > > > > > > removed, > > > > > > > similar to the USB case. > > > > > > > > > > > > > > This will change ALSA core. But there will be less PCM devices and > > > > > > > substreams, since the number of connected monitors Is decided by > > > > > > > the > > > > > > > actual GPU display pipeline. > > > > > > > > > > > > I like this option more, since I think it should be more like USB, > > > > > > but I've > > > > > > no idea how much work it would be from the alsa side, this patch was > > > > > > probably as deep into alsa as I've gone. > > > > > > > > > > Two things have to be considered for compatibility: > > > > > - ELD, channel map and jack detection: these are created per PCM > > > > > device, and extending to substream would confuse user space a lot. > > > > > In theory, it can be extended using subdevice number, but in anyway > > > > > this won't work with PulseAudio as is. > > > > > > > > > > - The per-pin assignment provides a more or less persistent route to a > > > > > certain device. Changing the assignment method may break the > > > > > previous setup. > > > > > > > > > > Also, the dynamic PCM creation / removal is an issue that has been > > > > > discussed many times. Unfortunately it won't work as is, at lest for > > > > > PA. Currently PA does probing of devices only at the card probe time. > > > > > The hotplug of USB-audio works because it's always tied with the > > > > > card. But in this case, the card remains while only the PCM devices > > > > > will be created / removed, thus the probe in PA won't be triggered. > > > > > > > > I guess that means we either have to hotplug entire (fake) cards or fix > > > > up > > > > userspace to support mst audio properly? > > > > > > It would work for HSW/BDW. But BYT/BSW and SKL share the same > > > controller for both HDMI and analog codecs, thus the card can't be > > > handled as hotplugged. > > > > > > > We had to do some minimal changes > > > > to the ddx drivers too to make sure they're rescanning the connector > > > > list > > > > properly. Imo since this is all new I think we could require PA to > > > > rescan > > > > the PCM dev list on hotplug events too to support DP MST. And we kinda > > > > do > > > > need hotplug at that level since if we'd hotplug the entire card we'd > > > > kill > > > > a stream that's running on some other display. > > > > > > > > And always registering all of them feels like a very bad hack too. > > > > > > Yeah, I pe
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
(Added pulseaudio-discuss to CC.) On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote: > At Mon, 22 Jun 2015 15:21:16 +, > Kaskinen, Tanu wrote: > > > > On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote: > > > On Mon, 2015-06-22 at 15:23 +0200, Takashi Iwai wrote: > > > > At Mon, 22 Jun 2015 14:54:29 +0200, > > > > Daniel Vetter wrote: > > > > > > > > > > On Fri, Jun 19, 2015 at 01:15:57PM +0200, Takashi Iwai wrote: > > > > > > At Fri, 19 Jun 2015 20:33:39 +1000, > > > > > > Dave Airlie wrote: > > > > > > > > > > > > > > On 19 June 2015 at 19:54, Lin, Mengdong > > > > > > > wrote: > > > > > > > > Hi Takashi/Dave, > > > > > > > > > > > > > > > > Shall we move or cc this discussion on audio driver side to > > > > > > > > ALSA ML? > > > > > > > > > > > > > > Oops I thought I had cc'ed these patches to alsa-devel as well > > > > > > > when I sent them. > > > > > > > > > > > > > > > I think we also need to decide how to manage PCM devices for DP > > > > > > > > MST. > > > > > > > > Now the HD-A driver create a PCM device for each pin, and the > > > > > > > > substream > > > > > > > > number is 1 for each PCM. Now with DP MST enabled, each pin can > > > > > > > > support > > > > > > > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL). > > > > > > > > > > > > > > > > There may be 2 options: > > > > > > > > -#1: Let an HDMI codec specify number of substreams, same as > > > > > > > > the number > > > > > > > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. > > > > > > > > Other > > > > > > > > vendors can also specify a value according to actual HW > > > > > > > > capabilities. > > > > > > > > > > > > > > > > So for HSW, we have 3x3 subtreams totally. But we only have 3 > > > > > > > > convertors > > > > > > > > (for 3 display pipelines), so we can open up to 3 substreams at > > > > > > > > the same > > > > > > > > time. When the audio driver finds all 3 convertors are used > > > > > > > > when opening > > > > > > > > a new substream, it will fail. > > > > > > > > > > > > > > One thing I noticed is the number of devices on a PIN is only > > > > > > > updated when > > > > > > > the MST device is plugged in so normally pins 5,6,7 have 0 > > > > > > > devices, and when > > > > > > > I plug in MST device, I get the 3 devices on port 6. So it seems > > > > > > > dynamic > > > > > > > enough at this point, though I guess it'll always be 0 or 3. > > > > > > > > > > > > > > > > - #2: Create PCM device dynamically. Only create a PCM devices > > > > > > > > for a device > > > > > > > > entry which connects to monitor with audio support. When the > > > > > > > > monitor > > > > > > > > is removed, the PCM device will be disconnected, closed and > > > > > > > > removed, > > > > > > > > similar to the USB case. > > > > > > > > > > > > > > > > This will change ALSA core. But there will be less PCM devices > > > > > > > > and > > > > > > > > substreams, since the number of connected monitors Is decided > > > > > > > > by the > > > > > > > > actual GPU display pipeline. > > > > > > > > > > > > > > I like this option more, since I think it should be more like > > > > > > > USB, but I've > > > > > > > no idea how much work it would be from the alsa side, this patch > > > > > > > was > > > > > > > probably as deep into alsa as I've gone. > > > > > > > > > > > > Two things have to be considered for compatibility: > > > > > > - ELD, channel map and jack detection: these are created per PCM > > > > > > device, and extending to substream would confuse user space a lot. > > > > > > In theory, it can be extended using subdevice number, but in > > > > > > anyway > > > > > > this won't work with PulseAudio as is. > > > > > > > > > > > > - The per-pin assignment provides a more or less persistent route > > > > > > to a > > > > > > certain device. Changing the assignment method may break the > > > > > > previous setup. > > > > > > > > > > > > Also, the dynamic PCM creation / removal is an issue that has been > > > > > > discussed many times. Unfortunately it won't work as is, at lest > > > > > > for > > > > > > PA. Currently PA does probing of devices only at the card probe > > > > > > time. > > > > > > The hotplug of USB-audio works because it's always tied with the > > > > > > card. But in this case, the card remains while only the PCM devices > > > > > > will be created / removed, thus the probe in PA won't be triggered. > > > > > > > > > > I guess that means we either have to hotplug entire (fake) cards or > > > > > fix up > > > > > userspace to support mst audio properly? > > > > > > > > It would work for HSW/BDW. But BYT/BSW and SKL share the same > > > > controller for both HDMI and analog codecs, thus the card can't be > > > > handled as hotplugged. > > > > > > > > > We had to do some minimal changes > > > > > to the ddx drivers too to make sure they're rescanning the connector > > > > > list > > > > > properly. Imo since this is all new I think we could
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
At Tue, 23 Jun 2015 07:51:22 +, Kaskinen, Tanu wrote: > > (Added pulseaudio-discuss to CC.) > > On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote: > > At Mon, 22 Jun 2015 15:21:16 +, > > Kaskinen, Tanu wrote: > > > > > > On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote: > > > > On Mon, 2015-06-22 at 15:23 +0200, Takashi Iwai wrote: > > > > > At Mon, 22 Jun 2015 14:54:29 +0200, > > > > > Daniel Vetter wrote: > > > > > > > > > > > > On Fri, Jun 19, 2015 at 01:15:57PM +0200, Takashi Iwai wrote: > > > > > > > At Fri, 19 Jun 2015 20:33:39 +1000, > > > > > > > Dave Airlie wrote: > > > > > > > > > > > > > > > > On 19 June 2015 at 19:54, Lin, Mengdong > > > > > > > > wrote: > > > > > > > > > Hi Takashi/Dave, > > > > > > > > > > > > > > > > > > Shall we move or cc this discussion on audio driver side to > > > > > > > > > ALSA ML? > > > > > > > > > > > > > > > > Oops I thought I had cc'ed these patches to alsa-devel as well > > > > > > > > when I sent them. > > > > > > > > > > > > > > > > > I think we also need to decide how to manage PCM devices for > > > > > > > > > DP MST. > > > > > > > > > Now the HD-A driver create a PCM device for each pin, and the > > > > > > > > > substream > > > > > > > > > number is 1 for each PCM. Now with DP MST enabled, each pin > > > > > > > > > can support > > > > > > > > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL). > > > > > > > > > > > > > > > > > > There may be 2 options: > > > > > > > > > -#1: Let an HDMI codec specify number of substreams, same as > > > > > > > > > the number > > > > > > > > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. > > > > > > > > > Other > > > > > > > > > vendors can also specify a value according to actual HW > > > > > > > > > capabilities. > > > > > > > > > > > > > > > > > > So for HSW, we have 3x3 subtreams totally. But we only have 3 > > > > > > > > > convertors > > > > > > > > > (for 3 display pipelines), so we can open up to 3 substreams > > > > > > > > > at the same > > > > > > > > > time. When the audio driver finds all 3 convertors are used > > > > > > > > > when opening > > > > > > > > > a new substream, it will fail. > > > > > > > > > > > > > > > > One thing I noticed is the number of devices on a PIN is only > > > > > > > > updated when > > > > > > > > the MST device is plugged in so normally pins 5,6,7 have 0 > > > > > > > > devices, and when > > > > > > > > I plug in MST device, I get the 3 devices on port 6. So it > > > > > > > > seems dynamic > > > > > > > > enough at this point, though I guess it'll always be 0 or 3. > > > > > > > > > > > > > > > > > > - #2: Create PCM device dynamically. Only create a PCM > > > > > > > > > devices for a device > > > > > > > > > entry which connects to monitor with audio support. When the > > > > > > > > > monitor > > > > > > > > > is removed, the PCM device will be disconnected, closed and > > > > > > > > > removed, > > > > > > > > > similar to the USB case. > > > > > > > > > > > > > > > > > > This will change ALSA core. But there will be less PCM > > > > > > > > > devices and > > > > > > > > > substreams, since the number of connected monitors Is decided > > > > > > > > > by the > > > > > > > > > actual GPU display pipeline. > > > > > > > > > > > > > > > > I like this option more, since I think it should be more like > > > > > > > > USB, but I've > > > > > > > > no idea how much work it would be from the alsa side, this > > > > > > > > patch was > > > > > > > > probably as deep into alsa as I've gone. > > > > > > > > > > > > > > Two things have to be considered for compatibility: > > > > > > > - ELD, channel map and jack detection: these are created per PCM > > > > > > > device, and extending to substream would confuse user space a > > > > > > > lot. > > > > > > > In theory, it can be extended using subdevice number, but in > > > > > > > anyway > > > > > > > this won't work with PulseAudio as is. > > > > > > > > > > > > > > - The per-pin assignment provides a more or less persistent route > > > > > > > to a > > > > > > > certain device. Changing the assignment method may break the > > > > > > > previous setup. > > > > > > > > > > > > > > Also, the dynamic PCM creation / removal is an issue that has been > > > > > > > discussed many times. Unfortunately it won't work as is, at lest > > > > > > > for > > > > > > > PA. Currently PA does probing of devices only at the card probe > > > > > > > time. > > > > > > > The hotplug of USB-audio works because it's always tied with the > > > > > > > card. But in this case, the card remains while only the PCM > > > > > > > devices > > > > > > > will be created / removed, thus the probe in PA won't be > > > > > > > triggered. > > > > > > > > > > > > I guess that means we either have to hotplug entire (fake) cards or > > > > > > fix up > > > > > > userspace to support mst audio properly? > > > > > > > > > > It would work for HSW/BDW. But BYT/BSW and SKL share the same > >
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Tue, 2015-06-23 at 10:06 +0200, Takashi Iwai wrote: > At Tue, 23 Jun 2015 07:51:22 +, > Kaskinen, Tanu wrote: > > > > (Added pulseaudio-discuss to CC.) > > > > On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote: > > > At Mon, 22 Jun 2015 15:21:16 +, > > > Kaskinen, Tanu wrote: > > > > > > > > On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote: > > > > > Tanu, what's your take on the effort for dynamically created PCMs > > > > > support for pulseaudio ? > > > > > > > > It's a significant amount of work, but I think PulseAudio should be > > > > improved to support this in any case, if other approaches make life > > > > miserable for driver developers. > > > > > > > > What would be the interface for getting notifications about new and > > > > removed PCM devices? udev? > > > > > > In general, yes. > > > > > > > PulseAudio (mostly) doesn't use the hw:X devices directly. Instead, it > > > > uses logical names like "front", "hdmi", "iec958", etc. Speaking of HDMI > > > > specifically, PulseAudio uses devices from "hdmi:X,0" to "hdmi:X,7". > > > > With this new dynamic PCM system, do these logical names still work? > > > > > > Unfortunately, this doesn't work for HDA as is, because of the > > > terribly arcane secret. For keeping the compatibility with the old > > > config, there is a static mapping of the hdmi:x,y and hw:x,z. > > > > > > Maybe we should introduce a new device class for dynamic HDMI/DP > > > device, something like dhdmi:x,y, to make things straightforward. > > > (Just a concept -- I'm not good at naming.) > > > > > > Alternatively, we may introduce a new argument to hdmi PCM to access > > > like "hdmi:CARD=x,SYSDEV=y". > > > > What happens if PulseAudio tries to open "dhdmi:x,y" or > > "hdmi:CARD=x,SYSDEV=y", when y points to a non-HDMI device? If it fails, > > then PulseAudio can replace its current "hdmi:x,[0-7]" devices with > > "hdmi:CARD=X,SYSDEV=[0-13]" and blindly try every hw PCM device. But if > > opening a non-HDMI device through "hdmi:CARD=x,SYSDEV=y" succeeds, then > > how is PulseAudio supposed to know which hw PCM devices are HDMI > > devices? > > It's a good question. I think this is the core part of the missing > pieces. > > What I have in my mind is to extend SNDRV_PCM_CLASS_* definition for > dedicated to HDMI/DP, e.g. SNDRV_PCM_CLASS_HDMI. The difference > between DP and HDMI can be specified in subclass optionally. Sounds good. Knowing the difference between HDMI, DisplayPort and Thunderbolt would be very nice too. It would enable better labelling in UIs. I have one minor concern, though: what if a PCM device isn't statically assigned to one output connector? Is it possible that some DSP is able to dynamically change the PCM routing between different outputs? In those cases the PCM class would be useless information (unless there are notifications when the class changes). I don't have any better ideas, though. I also wonder about compatibility between various combinations of kernel, alsa-lib and PA versions. An old kernel doesn't have dynamic PCM devices, and doesn't know about the HDMI PCM class. An old alsa-lib doesn't support the SYSDEV parameter, and doesn't know about the HDMI PCM class. An old PA version will only use the old-style "hdmi:x,y" device strings, and won't check the PCM class. There are 8 cases: 1: old kernel, old alsa-lib, old PA: No chance for regressions. 2: old kernel, old alsa-lib, new PA: The old alsa-lib version won't report the PCM class correctly. This can be handled by falling back to the old PA behaviour when an old alsa-lib version is detected at PA build time. 3: old kernel, new alsa-lib, old PA: No chance for regressions. 4: old kernel, new alsa-lib, new PA: The old kernel won't report the PCM class correctly. How should this be handled? Should PA do kernel version checking, and fall back to the old behaviour with old kernels? 5: new kernel, old alsa-lib, old PA: Do the kernel changes cause regressions on hardware that used to work, or do the changes only affect new hardware that has never worked? 6: new kernel, old alsa-lib, new PA: If PA uses the fallback strategy described in case 2, then this is equivalent to case 5. 7: new kernel, new alsa-lib, old PA: Equivalent to case 5. 8: new kernel, new alsa-lib, new PA: Everything works perfectly. -- Tanu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Tue, 2015-06-23 at 10:51 +0300, Tanu Kaskinen wrote: > (Added pulseaudio-discuss to CC.) > > On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote: > > At Mon, 22 Jun 2015 15:21:16 +, > > Kaskinen, Tanu wrote: > > > > > > On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote: > > > > Btw, the topology core now also dynamically > > > > creates/removes mixer controls, can PA handle this atm ? > > > > > > No, PA checks the mixer controls only when loading a new card. > > > Dynamically added controls are ignored. Dynamically removed controls > > > just cause silent failure, at least when setting volume (I didn't check > > > other use cases). That is, changing the volume appears to succeed, but > > > nothing actually happens. > > > > Won't PA use ELD or other information? The corresponding controls to > > HDMI/DP will be created / deleted dynamically together with a PCM > > device, I suppose. > > Yes, PA uses ELD. If mixer controls become dynamic too, then that's > another thing to implement. Liam, how does the userspace know when the new PCM is ready to use? If new mixer controls are added too, it has to be defined which gets created first: the PCM device or the mixer controls. I think it would be best if the mixer controls get created first, and when the new PCM device appears, it's immediately fully ready to be used. -- Tanu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote: > At Mon, 22 Jun 2015 15:21:16 +, > Kaskinen, Tanu wrote: > > PulseAudio (mostly) doesn't use the hw:X devices directly. Instead, it > > uses logical names like "front", "hdmi", "iec958", etc. Speaking of HDMI > > specifically, PulseAudio uses devices from "hdmi:X,0" to "hdmi:X,7". > > With this new dynamic PCM system, do these logical names still work? > > Unfortunately, this doesn't work for HDA as is, because of the > terribly arcane secret. For keeping the compatibility with the old > config, there is a static mapping of the hdmi:x,y and hw:x,z. Yes, the mapping is like this: y = 0, z = 3 y = 1, z = 7 y = 2, z = 8 y = 3, z = 9 etc. Now I'm wondering if this is HDA specific (your wording suggests that it is)? For HDMI ELD information and jack detection support, PulseAudio has been assuming this particular mapping. If other drivers have been using a different mapping, then ELD and jack detection support has been and continues to be broken for other drivers in PA. -- Tanu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Fri, 2015-06-26 at 11:50 +0100, Kaskinen, Tanu wrote: > On Tue, 2015-06-23 at 10:51 +0300, Tanu Kaskinen wrote: > > (Added pulseaudio-discuss to CC.) > > > > On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote: > > > At Mon, 22 Jun 2015 15:21:16 +, > > > Kaskinen, Tanu wrote: > > > > > > > > On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote: > > > > > Btw, the topology core now also dynamically > > > > > creates/removes mixer controls, can PA handle this atm ? > > > > > > > > No, PA checks the mixer controls only when loading a new card. > > > > Dynamically added controls are ignored. Dynamically removed controls > > > > just cause silent failure, at least when setting volume (I didn't check > > > > other use cases). That is, changing the volume appears to succeed, but > > > > nothing actually happens. > > > > > > Won't PA use ELD or other information? The corresponding controls to > > > HDMI/DP will be created / deleted dynamically together with a PCM > > > device, I suppose. > > > > Yes, PA uses ELD. If mixer controls become dynamic too, then that's > > another thing to implement. > > Liam, how does the userspace know when the new PCM is ready to use? It's generally ready when the PCM is created iirc. > If > new mixer controls are added too, it has to be defined which gets > created first: the PCM device or the mixer controls. I think it would be > best if the mixer controls get created first, and when the new PCM > device appears, it's immediately fully ready to be used. > I agree, adding mixers first make sense. Liam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
Hi Takashi/Dave,
Shall we move or cc this discussion on audio driver side to ALSA ML?
I think we also need to decide how to manage PCM devices for DP MST.
Now the HD-A driver create a PCM device for each pin, and the substream
number is 1 for each PCM. Now with DP MST enabled, each pin can support
multiple streams (e.g. 3 on Intel HSW/BDW/SKL).
There may be 2 options:
-#1: Let an HDMI codec specify number of substreams, same as the number
of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other
vendors can also specify a value according to actual HW capabilities.
So for HSW, we have 3x3 subtreams totally. But we only have 3 convertors
(for 3 display pipelines), so we can open up to 3 substreams at the same
time. When the audio driver finds all 3 convertors are used when opening
a new substream, it will fail.
- #2: Create PCM device dynamically. Only create a PCM devices for a device
entry which connects to monitor with audio support. When the monitor
is removed, the PCM device will be disconnected, closed and removed,
similar to the USB case.
This will change ALSA core. But there will be less PCM devices and
substreams, since the number of connected monitors Is decided by the
actual GPU display pipeline.
Could you share your preference on these 2 options or other suggestions?
Thanks
Mengdong
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Dave Airlie
> Sent: Wednesday, June 17, 2015 12:02 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream
> to hda codec.
>
> From: Dave Airlie
>
> Add new verbs GET_DP_STREAM_ID and SET_DP_STREAM_ID from Intel docs.
> get stream id and print in proc
> split ELD to be per device not per pin
> handle pd/eldv per device not per pin
> setup codec->dp_mst earlier.
>
> Signed-off-by: Dave Airlie
> ---
> include/sound/hda_verbs.h | 2 +
> sound/pci/hda/hda_codec.c | 1 +
> sound/pci/hda/hda_proc.c | 5 +-
> sound/pci/hda/patch_hdmi.c | 181
> +++--
> 4 files changed, 131 insertions(+), 58 deletions(-)
>
> diff --git a/include/sound/hda_verbs.h b/include/sound/hda_verbs.h index
> d0509db..3b62ac5 100644
> --- a/include/sound/hda_verbs.h
> +++ b/include/sound/hda_verbs.h
> @@ -75,6 +75,7 @@ enum {
> #define AC_VERB_GET_HDMI_CHAN_SLOT 0x0f34
> #define AC_VERB_GET_DEVICE_SEL 0xf35
> #define AC_VERB_GET_DEVICE_LIST 0xf36
> +#define AC_VERB_GET_DP_STREAM_ID 0xf3c
>
> /*
> * SET verbs
> @@ -115,6 +116,7 @@ enum {
> #define AC_VERB_SET_HDMI_CP_CTRL 0x733
> #define AC_VERB_SET_HDMI_CHAN_SLOT 0x734
> #define AC_VERB_SET_DEVICE_SEL 0x735
> +#define AC_VERB_SET_DP_STREAM_ID 0x73C
>
> /*
> * Parameter IDs
> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index
> 5645481..3981c63 100644
> --- a/sound/pci/hda/hda_codec.c
> +++ b/sound/pci/hda/hda_codec.c
> @@ -482,6 +482,7 @@ int snd_hda_get_devices(struct hda_codec *codec,
> hda_nid_t nid,
> }
> return devices;
> }
> +EXPORT_SYMBOL_GPL(snd_hda_get_devices);
>
> /*
> * destructor
> diff --git a/sound/pci/hda/hda_proc.c b/sound/pci/hda/hda_proc.c index
> baaf7ed0..39fac53 100644
> --- a/sound/pci/hda/hda_proc.c
> +++ b/sound/pci/hda/hda_proc.c
> @@ -644,10 +644,13 @@ static void print_device_list(struct snd_info_buffer
> *buffer,
> int i, curr = -1;
> u8 dev_list[AC_MAX_DEV_LIST_LEN];
> int devlist_len;
> + int dp_s_id;
>
> + dp_s_id = snd_hda_codec_read(codec, nid, 0,
> + AC_VERB_GET_DP_STREAM_ID, 0);
> devlist_len = snd_hda_get_devices(codec, nid, dev_list,
> AC_MAX_DEV_LIST_LEN);
> - snd_iprintf(buffer, " Devices: %d\n", devlist_len);
> + snd_iprintf(buffer, " Devices: %d: 0x%x\n", devlist_len, dp_s_id);
> if (devlist_len <= 0)
> return;
>
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index
> 5f44f60..8272656 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -68,6 +68,17 @@ struct hdmi_spec_per_cvt {
> /* max. connections to a widget */
> #define HDA_MAX_CONNECTIONS 32
>
> +struct hdmi_spec_per_pin;
> +#define HDA_MAX_DEVICES 3
> +struct hdmi_spec_per_device {
> + struct hdmi_spec_per_pin *pin;
> + int device_idx;
> + struct hdmi_eld sink_eld;
> +#ifdef CONFIG_PROC_FS
> + struct snd_info_entry *proc_entry;
> +#endif
> +};
> +
> struct hdmi_spec_pe
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On 19 June 2015 at 19:54, Lin, Mengdong wrote:
> Hi Takashi/Dave,
>
> Shall we move or cc this discussion on audio driver side to ALSA ML?
Oops I thought I had cc'ed these patches to alsa-devel as well when I sent them.
> I think we also need to decide how to manage PCM devices for DP MST.
> Now the HD-A driver create a PCM device for each pin, and the substream
> number is 1 for each PCM. Now with DP MST enabled, each pin can support
> multiple streams (e.g. 3 on Intel HSW/BDW/SKL).
>
> There may be 2 options:
> -#1: Let an HDMI codec specify number of substreams, same as the number
> of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other
> vendors can also specify a value according to actual HW capabilities.
>
> So for HSW, we have 3x3 subtreams totally. But we only have 3 convertors
> (for 3 display pipelines), so we can open up to 3 substreams at the same
> time. When the audio driver finds all 3 convertors are used when opening
> a new substream, it will fail.
One thing I noticed is the number of devices on a PIN is only updated when
the MST device is plugged in so normally pins 5,6,7 have 0 devices, and when
I plug in MST device, I get the 3 devices on port 6. So it seems dynamic
enough at this point, though I guess it'll always be 0 or 3.
>
> - #2: Create PCM device dynamically. Only create a PCM devices for a device
> entry which connects to monitor with audio support. When the monitor
> is removed, the PCM device will be disconnected, closed and removed,
> similar to the USB case.
>
> This will change ALSA core. But there will be less PCM devices and
> substreams, since the number of connected monitors Is decided by the
> actual GPU display pipeline.
I like this option more, since I think it should be more like USB, but I've
no idea how much work it would be from the alsa side, this patch was
probably as deep into alsa as I've gone.
Dave.
>> Signed-off-by: Dave Airlie
>> ---
>> include/sound/hda_verbs.h | 2 +
>> sound/pci/hda/hda_codec.c | 1 +
>> sound/pci/hda/hda_proc.c | 5 +-
>> sound/pci/hda/patch_hdmi.c | 181
>> +++--
>> 4 files changed, 131 insertions(+), 58 deletions(-)
>>
>> diff --git a/include/sound/hda_verbs.h b/include/sound/hda_verbs.h index
>> d0509db..3b62ac5 100644
>> --- a/include/sound/hda_verbs.h
>> +++ b/include/sound/hda_verbs.h
>> @@ -75,6 +75,7 @@ enum {
>> #define AC_VERB_GET_HDMI_CHAN_SLOT 0x0f34
>> #define AC_VERB_GET_DEVICE_SEL 0xf35
>> #define AC_VERB_GET_DEVICE_LIST 0xf36
>> +#define AC_VERB_GET_DP_STREAM_ID 0xf3c
>>
>> /*
>> * SET verbs
>> @@ -115,6 +116,7 @@ enum {
>> #define AC_VERB_SET_HDMI_CP_CTRL 0x733
>> #define AC_VERB_SET_HDMI_CHAN_SLOT 0x734
>> #define AC_VERB_SET_DEVICE_SEL 0x735
>> +#define AC_VERB_SET_DP_STREAM_ID 0x73C
>>
>> /*
>> * Parameter IDs
>> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index
>> 5645481..3981c63 100644
>> --- a/sound/pci/hda/hda_codec.c
>> +++ b/sound/pci/hda/hda_codec.c
>> @@ -482,6 +482,7 @@ int snd_hda_get_devices(struct hda_codec *codec,
>> hda_nid_t nid,
>> }
>> return devices;
>> }
>> +EXPORT_SYMBOL_GPL(snd_hda_get_devices);
>>
>> /*
>> * destructor
>> diff --git a/sound/pci/hda/hda_proc.c b/sound/pci/hda/hda_proc.c index
>> baaf7ed0..39fac53 100644
>> --- a/sound/pci/hda/hda_proc.c
>> +++ b/sound/pci/hda/hda_proc.c
>> @@ -644,10 +644,13 @@ static void print_device_list(struct snd_info_buffer
>> *buffer,
>> int i, curr = -1;
>> u8 dev_list[AC_MAX_DEV_LIST_LEN];
>> int devlist_len;
>> + int dp_s_id;
>>
>> + dp_s_id = snd_hda_codec_read(codec, nid, 0,
>> + AC_VERB_GET_DP_STREAM_ID, 0);
>> devlist_len = snd_hda_get_devices(codec, nid, dev_list,
>> AC_MAX_DEV_LIST_LEN);
>> - snd_iprintf(buffer, " Devices: %d\n", devlist_len);
>> + snd_iprintf(buffer, " Devices: %d: 0x%x\n", devlist_len, dp_s_id);
>> if (devlist_len <= 0)
>> return;
>>
>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index
>> 5f44f60..8272656 100644
>> --- a/sound/pci/hda/patch_hdmi.c
>> +++ b/sound/pci/hda/patch_hdmi.c
>> @@ -68,6 +68,17 @@ struct hdmi_spec_per_cvt {
>> /* max. connections to a widget */
>> #define HDA_MAX_CONNECTIONS 32
>>
>> +struct hdmi_spec_per_pin;
>> +#define HDA_MAX_DEVICES 3
>> +struct hdmi_spec_per_device {
>> + struct hdmi_spec_per_pin *pin;
>> + int device_idx;
>> + struct hdmi_eld sink_eld;
>> +#ifdef CONFIG_PROC_FS
>> + struct snd_info_entry *proc_entry;
>> +#endif
>> +};
>> +
>> struct hdmi_spec_per_pin {
>> hda_nid_t pin_nid;
>> int num_mux_nids;
>> @@ -76,7 +87,11 @@ struct hdmi_spec_per_pin {
>> hda_nid_t cvt_nid;
>>
>> struct hda_codec *codec;
>> - struct hdmi_eld sink_eld;
>> +
>> + int
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
At Fri, 19 Jun 2015 20:33:39 +1000,
Dave Airlie wrote:
>
> On 19 June 2015 at 19:54, Lin, Mengdong wrote:
> > Hi Takashi/Dave,
> >
> > Shall we move or cc this discussion on audio driver side to ALSA ML?
>
> Oops I thought I had cc'ed these patches to alsa-devel as well when I sent
> them.
>
> > I think we also need to decide how to manage PCM devices for DP MST.
> > Now the HD-A driver create a PCM device for each pin, and the substream
> > number is 1 for each PCM. Now with DP MST enabled, each pin can support
> > multiple streams (e.g. 3 on Intel HSW/BDW/SKL).
> >
> > There may be 2 options:
> > -#1: Let an HDMI codec specify number of substreams, same as the number
> > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other
> > vendors can also specify a value according to actual HW capabilities.
> >
> > So for HSW, we have 3x3 subtreams totally. But we only have 3 convertors
> > (for 3 display pipelines), so we can open up to 3 substreams at the same
> > time. When the audio driver finds all 3 convertors are used when opening
> > a new substream, it will fail.
>
> One thing I noticed is the number of devices on a PIN is only updated when
> the MST device is plugged in so normally pins 5,6,7 have 0 devices, and when
> I plug in MST device, I get the 3 devices on port 6. So it seems dynamic
> enough at this point, though I guess it'll always be 0 or 3.
> >
> > - #2: Create PCM device dynamically. Only create a PCM devices for a device
> > entry which connects to monitor with audio support. When the monitor
> > is removed, the PCM device will be disconnected, closed and removed,
> > similar to the USB case.
> >
> > This will change ALSA core. But there will be less PCM devices and
> > substreams, since the number of connected monitors Is decided by the
> > actual GPU display pipeline.
>
> I like this option more, since I think it should be more like USB, but I've
> no idea how much work it would be from the alsa side, this patch was
> probably as deep into alsa as I've gone.
Two things have to be considered for compatibility:
- ELD, channel map and jack detection: these are created per PCM
device, and extending to substream would confuse user space a lot.
In theory, it can be extended using subdevice number, but in anyway
this won't work with PulseAudio as is.
- The per-pin assignment provides a more or less persistent route to a
certain device. Changing the assignment method may break the
previous setup.
Also, the dynamic PCM creation / removal is an issue that has been
discussed many times. Unfortunately it won't work as is, at lest for
PA. Currently PA does probing of devices only at the card probe time.
The hotplug of USB-audio works because it's always tied with the
card. But in this case, the card remains while only the PCM devices
will be created / removed, thus the probe in PA won't be triggered.
Takashi
>
> Dave.
>
> >> Signed-off-by: Dave Airlie
> >> ---
> >> include/sound/hda_verbs.h | 2 +
> >> sound/pci/hda/hda_codec.c | 1 +
> >> sound/pci/hda/hda_proc.c | 5 +-
> >> sound/pci/hda/patch_hdmi.c | 181
> >> +++--
> >> 4 files changed, 131 insertions(+), 58 deletions(-)
> >>
> >> diff --git a/include/sound/hda_verbs.h b/include/sound/hda_verbs.h index
> >> d0509db..3b62ac5 100644
> >> --- a/include/sound/hda_verbs.h
> >> +++ b/include/sound/hda_verbs.h
> >> @@ -75,6 +75,7 @@ enum {
> >> #define AC_VERB_GET_HDMI_CHAN_SLOT 0x0f34
> >> #define AC_VERB_GET_DEVICE_SEL 0xf35
> >> #define AC_VERB_GET_DEVICE_LIST 0xf36
> >> +#define AC_VERB_GET_DP_STREAM_ID 0xf3c
> >>
> >> /*
> >> * SET verbs
> >> @@ -115,6 +116,7 @@ enum {
> >> #define AC_VERB_SET_HDMI_CP_CTRL 0x733
> >> #define AC_VERB_SET_HDMI_CHAN_SLOT 0x734
> >> #define AC_VERB_SET_DEVICE_SEL 0x735
> >> +#define AC_VERB_SET_DP_STREAM_ID 0x73C
> >>
> >> /*
> >> * Parameter IDs
> >> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index
> >> 5645481..3981c63 100644
> >> --- a/sound/pci/hda/hda_codec.c
> >> +++ b/sound/pci/hda/hda_codec.c
> >> @@ -482,6 +482,7 @@ int snd_hda_get_devices(struct hda_codec *codec,
> >> hda_nid_t nid,
> >> }
> >> return devices;
> >> }
> >> +EXPORT_SYMBOL_GPL(snd_hda_get_devices);
> >>
> >> /*
> >> * destructor
> >> diff --git a/sound/pci/hda/hda_proc.c b/sound/pci/hda/hda_proc.c index
> >> baaf7ed0..39fac53 100644
> >> --- a/sound/pci/hda/hda_proc.c
> >> +++ b/sound/pci/hda/hda_proc.c
> >> @@ -644,10 +644,13 @@ static void print_device_list(struct snd_info_buffer
> >> *buffer,
> >> int i, curr = -1;
> >> u8 dev_list[AC_MAX_DEV_LIST_LEN];
> >> int devlist_len;
> >> + int dp_s_id;
> >>
> >> + dp_s_id = snd_hda_codec_read(codec, nid, 0,
> >> + AC_VERB_GET_DP_STREAM_ID, 0);
> >> devlist_len = snd_hda_get_devi
