[alsa-devel] DP MST audio support
Hi, So I have a branch that makes no sound, http://cgit.freedesktop.org/~airlied/linux/log/?h=dp-mst-audio and I'm not sure where I need to turn to next, The Intel docs I've read are kinda vague, assuming you know lots of things I clearly don't. so in theory my branch, sets up the SDP stream to the monitor in the payload creation, enables the codec in the intel GPU driver, and passes the ELD to the audio driver. The audio driver uses the device list to get the presence/valid bits per device, and manages to retrieve the ELD. I even create ELD files in /proc/asound/HDMI/ that have sensible values in them So it looks like I'm just missing some routing somewhere, most likely in the audio driver, then again I could be missing a lot more than that. Just looking for any ideas or knowledge people may have locked in their brains or inside their firewalls. Dave.
On 12 May 2015 at 11:50, Dave Airlie <airlied@gmail.com> wrote:
Hi,
So I have a branch that makes no sound, http://cgit.freedesktop.org/~airlied/linux/log/?h=dp-mst-audio
and I'm not sure where I need to turn to next,
The Intel docs I've read are kinda vague, assuming you know lots of things I clearly don't.
so in theory my branch, sets up the SDP stream to the monitor in the payload creation, enables the codec in the intel GPU driver, and passes the ELD to the audio driver.
The audio driver uses the device list to get the presence/valid bits per device, and manages to retrieve the ELD. I even create ELD files in /proc/asound/HDMI/ that have sensible values in them
So it looks like I'm just missing some routing somewhere, most likely in the audio driver, then again I could be missing a lot more than that.
Just looking for any ideas or knowledge people may have locked in their brains or inside their firewalls.
Okay the branch now has audio on my test setup, I've had to hack out the intel_not_share_assigned_cvt function it appears to do bad things, I set pin 6 to connection 0 (pin 2), the later sets on pin 5/7 to connection 1 by that function seems to reprogram pin 6. I'm guessing the connection is assigned to a device not a pin in the new hw, and the same device is routed via pin 5/7 so I end up trashing it. my test setup is a Haswell Lenovo t440s + docking station + Dell U2410. Dave.
On 12 May 2015 at 13:27, Dave Airlie <airlied@gmail.com> wrote:
On 12 May 2015 at 11:50, Dave Airlie <airlied@gmail.com> wrote:
Hi,
So I have a branch that makes no sound, http://cgit.freedesktop.org/~airlied/linux/log/?h=dp-mst-audio
and I'm not sure where I need to turn to next,
The Intel docs I've read are kinda vague, assuming you know lots of things I clearly don't.
so in theory my branch, sets up the SDP stream to the monitor in the payload creation, enables the codec in the intel GPU driver, and passes the ELD to the audio driver.
The audio driver uses the device list to get the presence/valid bits per device, and manages to retrieve the ELD. I even create ELD files in /proc/asound/HDMI/ that have sensible values in them
So it looks like I'm just missing some routing somewhere, most likely in the audio driver, then again I could be missing a lot more than that.
Just looking for any ideas or knowledge people may have locked in their brains or inside their firewalls.
Okay the branch now has audio on my test setup,
I've had to hack out the intel_not_share_assigned_cvt function it appears to do bad things, I set pin 6 to connection 0 (pin 2), the later sets on pin 5/7 to connection 1 by that function seems to reprogram pin 6.
I'm guessing the connection is assigned to a device not a pin in the new hw, and the same device is routed via pin 5/7 so I end up trashing it.
my test setup is a Haswell Lenovo t440s + docking station + Dell U2410.
ping audio guys? can someone from alsa please take a look or some interest in this? The graphics side patches are fairly trivial, also it would be good to get a good explaination of how the hw works, from what I can see devices get connections not pins on this hw, and I notice that I don't always get 3 devices, so I'm not sure if devices are a dynamic thing we should be reprobing on some signal. Dave.
At Thu, 14 May 2015 09:10:33 +1000, Dave Airlie wrote:
On 12 May 2015 at 13:27, Dave Airlie <airlied@gmail.com> wrote:
On 12 May 2015 at 11:50, Dave Airlie <airlied@gmail.com> wrote:
Hi,
So I have a branch that makes no sound, http://cgit.freedesktop.org/~airlied/linux/log/?h=dp-mst-audio
and I'm not sure where I need to turn to next,
The Intel docs I've read are kinda vague, assuming you know lots of things I clearly don't.
so in theory my branch, sets up the SDP stream to the monitor in the payload creation, enables the codec in the intel GPU driver, and passes the ELD to the audio driver.
The audio driver uses the device list to get the presence/valid bits per device, and manages to retrieve the ELD. I even create ELD files in /proc/asound/HDMI/ that have sensible values in them
So it looks like I'm just missing some routing somewhere, most likely in the audio driver, then again I could be missing a lot more than that.
Just looking for any ideas or knowledge people may have locked in their brains or inside their firewalls.
Okay the branch now has audio on my test setup,
I've had to hack out the intel_not_share_assigned_cvt function it appears to do bad things, I set pin 6 to connection 0 (pin 2), the later sets on pin 5/7 to connection 1 by that function seems to reprogram pin 6.
I'm guessing the connection is assigned to a device not a pin in the new hw, and the same device is routed via pin 5/7 so I end up trashing it.
my test setup is a Haswell Lenovo t440s + docking station + Dell U2410.
ping audio guys?
can someone from alsa please take a look or some interest in this?
Sorry, I've been on vacation for last two weeks. Now still swimming in the flood of backlogs...
The graphics side patches are fairly trivial, also it would be good to get a good explaination of how the hw works,
from what I can see devices get connections not pins on this hw, and I notice that I don't always get 3 devices, so I'm not sure if devices are a dynamic thing we should be reprobing on some signal.
The intel_not_share_assigned_cvt() was needed for Haswell HDMI/DP as there was static routing between the pin and the converter widgets although the codec graph shows it's selectable. Was the pin default config of pin 6 enabled by BIOS properly? In anyway, Intel people should have a better clue about this; it's been always a strange behavior that is tied with the graphics... thanks, Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, May 18, 2015 5:21 PM
At Thu, 14 May 2015 09:10:33 +1000, Dave Airlie wrote:
On 12 May 2015 at 13:27, Dave Airlie <airlied@gmail.com> wrote:
On 12 May 2015 at 11:50, Dave Airlie <airlied@gmail.com> wrote:
Hi,
So I have a branch that makes no sound, http://cgit.freedesktop.org/~airlied/linux/log/?h=dp-mst-audio
and I'm not sure where I need to turn to next,
The Intel docs I've read are kinda vague, assuming you know lots of things I clearly don't.
so in theory my branch, sets up the SDP stream to the monitor in the payload creation, enables the codec in the intel GPU driver, and passes the ELD to the audio driver.
The audio driver uses the device list to get the presence/valid bits per device, and manages to retrieve the ELD. I even create ELD files in /proc/asound/HDMI/ that have sensible values in them
So it looks like I'm just missing some routing somewhere, most likely in the audio driver, then again I could be missing a lot more than that.
Just looking for any ideas or knowledge people may have locked in their brains or inside their firewalls.
Okay the branch now has audio on my test setup,
I've had to hack out the intel_not_share_assigned_cvt function it appears to do bad things, I set pin 6 to connection 0 (pin 2), the later sets on pin 5/7 to connection 1 by that function seems to reprogram
pin 6.
I'm guessing the connection is assigned to a device not a pin in the new hw, and the same device is routed via pin 5/7 so I end up trashing it.
my test setup is a Haswell Lenovo t440s + docking station + Dell U2410.
ping audio guys?
can someone from alsa please take a look or some interest in this?
Sorry, I've been on vacation for last two weeks. Now still swimming in the flood of backlogs...
Hi Artie, Sorry for the late reply. We don't have Haswell Lenovo t440s atm, so could you share more info? - Dell U2410 should support both HDMI and DP input. But I guess it cannot support DP MST, right? - Are you connecting this monitor a DP cable? Which DDI port is used? DDI B, C or D? - Does audio fail after i915 enables DP MST? - Is patch "snd/hdmi: hack out haswell codec workaround" the only change on audio driver side?
The graphics side patches are fairly trivial, also it would be good to get a good explaination of how the hw works,
from what I can see devices get connections not pins on this hw, and I notice that I don't always get 3 devices, so I'm not sure if devices are a dynamic thing we should be reprobing on some signal.
Do you mean 3 PCM devices here, like pcmC0D3p, pcmC0D7p, pcmC0D8p? Now the devices are not dynamic, a PCM device is created on each pin. It seems we need to revise this for DP MST, since a pin can be used to send up to 3 independent streams on Intel GPU which has 3 display pipelines.
The intel_not_share_assigned_cvt() was needed for Haswell HDMI/DP as there was static routing between the pin and the converter widgets although the codec graph shows it's selectable.
We need to check why this fails. Even if MST is enabled, the convertors should also be selectable.
Was the pin default config of pin 6 enabled by BIOS properly?
In anyway, Intel people should have a better clue about this; it's been always a strange behavior that is tied with the graphics...
thanks,
Takashi
Just to fill in the info on this one.
We don't have Haswell Lenovo t440s atm, so could you share more info? - Dell U2410 should support both HDMI and DP input. But I guess it cannot support DP MST, right? - Are you connecting this monitor a DP cable? Which DDI port is used? DDI B, C or D? - Does audio fail after i915 enables DP MST? - Is patch "snd/hdmi: hack out haswell codec workaround" the only change on audio driver side?
Yes its a DP SST input on the U2410, and I'm using that for the audio. It's connected to the Lenovo dock with DP cable. The dock is an MST device. The dock is connected to DDI C I think, and if the dock is operated in SST mode audio works, but in MST mode audio fails. (operating the dock in SST mode isn't useful though since only one of the multiple outputs works then).
The graphics side patches are fairly trivial, also it would be good to get a good explaination of how the hw works,
from what I can see devices get connections not pins on this hw, and I notice that I don't always get 3 devices, so I'm not sure if devices are a dynamic thing we should be reprobing on some signal.
Do you mean 3 PCM devices here, like pcmC0D3p, pcmC0D7p, pcmC0D8p? Now the devices are not dynamic, a PCM device is created on each pin. It seems we need to revise this for DP MST, since a pin can be used to send up to 3 independent streams on Intel GPU which has 3 display pipelines.
No I mean the "Devices" from snd_hda_get_devices. Dave.
Hi Dave, Sorry for interrupt. I'm currently testing the MST audio with HSW. Could you please help tell how I can say DP1.2 works? I connect a DP1.2 monitor to HSW and a DP1.1 monitor to DP1.2 monitor output. In this mode, can I make the 2 monitors show different contents? Thanks. Regards, Libin
-----Original Message----- From: Dave Airlie [mailto:airlied@gmail.com] Sent: Friday, June 19, 2015 6:38 PM To: Lin, Mengdong Cc: Takashi Iwai; Yang, Libin; Lu, Han; alsa-devel@alsa-project.org; intel- gfx@lists.freedesktop.org; Girdwood, Liam R Subject: Re: [alsa-devel] DP MST audio support
Just to fill in the info on this one.
We don't have Haswell Lenovo t440s atm, so could you share more info? - Dell U2410 should support both HDMI and DP input. But I guess it cannot support DP MST, right? - Are you connecting this monitor a DP cable? Which DDI port is used? DDI B, C or D? - Does audio fail after i915 enables DP MST? - Is patch "snd/hdmi: hack out haswell codec workaround" the only change on audio driver side?
Yes its a DP SST input on the U2410, and I'm using that for the audio.
It's connected to the Lenovo dock with DP cable. The dock is an MST device.
The dock is connected to DDI C I think, and if the dock is operated in SST mode audio works, but in MST mode audio fails. (operating the dock in SST mode isn't useful though since only one of the multiple outputs works then).
The graphics side patches are fairly trivial, also it would be good to get a good explaination of how the hw works,
from what I can see devices get connections not pins on this hw, and I notice that I don't always get 3 devices, so I'm not sure if devices are a dynamic thing we should be reprobing on some signal.
Do you mean 3 PCM devices here, like pcmC0D3p, pcmC0D7p, pcmC0D8p? Now the devices are not dynamic, a PCM device is created on each pin. It seems we need to revise this for DP MST, since a pin can be used to send up to 3 independent streams on Intel GPU which has 3 display pipelines.
No I mean the "Devices" from snd_hda_get_devices.
Dave.
participants (4)
-
Dave Airlie -
Lin, Mengdong -
Takashi Iwai -
Yang, Libin