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