[alsa-devel] DP1.2 MST audio support discussion

Yang, Libin libin.yang at intel.com
Tue Oct 27 09:45:17 CET 2015


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 at linux.ie; tanuk at 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 at 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 at 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


More information about the Alsa-devel mailing list