Re: DP1.2 MST audio support discussion

[Takashi Iwai <tiwai@suse.de>]

On Tue, 27 Oct 2015 09:45:17 +0100,
Yang, Libin wrote:
> 
> 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?)

I don't understand the question.  Could you elaborate?

> 2. chmap. 
> The chmap will use the old method. Each virtual pin has its own chmap.

Yes, and this doesn't change.  The chmap is assigned to each PCM
stream, basically, so it's tied to the assigned MST dev.

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

It's is no big deal in either way, just choose the simpler one.

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

... if we implement it.  Actually this behavior (returning -ENODEV) is
not mandatory and needs investigation beforehand, whether this breaks
any applications, especially PA.

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

Is this a problem?  The PM scheme doesn't change, after all.


Takashi

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