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