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

[Takashi Iwai]

On Wed, 11 Nov 2015 09:11:49 +0100,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai at suse.de]
> > Sent: Wednesday, November 11, 2015 4:06 PM
> > To: Yang, Libin
> > Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied at linux.ie';
> > 'tanuk at iki.fi'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu,
> > Han; Nikula, Jani
> > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > 
> > On Wed, 11 Nov 2015 08:58:29 +0100,
> > Yang, Libin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Yang, Libin
> > > > Sent: Wednesday, November 11, 2015 10:04 AM
> > > > To: David Henningsson; Takashi Iwai
> > > > Cc: Lin, Mengdong; Raymond Yau; airlied at linux.ie; tanuk at iki.fi; ALSA
> > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: David Henningsson
> > [mailto:david.henningsson at canonical.com]
> > > > > Sent: Tuesday, November 10, 2015 3:45 PM
> > > > > To: Yang, Libin; Takashi Iwai
> > > > > Cc: Lin, Mengdong; Raymond Yau; airlied at linux.ie; tanuk at iki.fi;
> > ALSA
> > > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani
> > > > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > >
> > > > >
> > > > >
> > > > > On 2015-11-10 07:46, Yang, Libin wrote:
> > > > > > Hi David,
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: David Henningsson
> > > > [mailto:david.henningsson at canonical.com]
> > > > > >> Sent: Thursday, November 05, 2015 5:07 PM
> > > > > >> To: Yang, Libin; Takashi Iwai
> > > > > >> Cc: Lin, Mengdong; Raymond Yau; airlied at linux.ie; tanuk at iki.fi;
> > > > ALSA
> > > > > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula,
> > Jani
> > > > > >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> So I'm asking my question again. What would happen (on Intel
> > > > > hardware),
> > > > > >> if you stream audio to a converter node on the audio codec, and
> > > > there
> > > > > is
> > > > > >> no pin node connected to that converter node?
> > > > > >
> > > > > > I changed the audio driver and did the test today. The test is:
> > > > > > 1. Pin 5 connect to converter 2 and playback, there is sound from
> > pin
> > > > 5.
> > > > > > 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2),
> > no
> > > > > sound.
> > > > > > 3. Pin 5 connect back to cvt 2, there is sound, playback is normal.
> > > > > >
> > > > > > And in step 2, the playback is still ongoing but no sound is out from
> > > > any
> > > > > pin.
> > > > >
> > > > > Sounds good to me, thanks for testing. Is this workaround
> > something
> > > > we
> > > > > could utilize in order to not break userspace? (This is a question for
> > > > > both you and Takashi.)
> > > > >
> > > > > What we'll end up is essentially three types of objects:
> > > > >
> > > > >   * PCM device (5 devices, 3,7,8,9,10)
> > > > >    - all five devices are allocated when the driver initializes
> > > >
> > > > This should be for Intel platform, right? The actually number
> > > > should be:
> > > > pin number + device entry number - 1.
> > > > On intel platform, pin_num = 3, dev_num = 3, so it will be 5.
> > > >
> > > > >    - all kcontrols are always bound to the PCM device (jack kctl, eld
> > > > > kctl, iec958 kctls etc)
> > > >
> > > > Sure, I agree on it.
> > > >
> > > > >
> > > > >   * Monitor (pin + MST index)
> > > > >    - dynamically bound to a PCM at monitor plug-in time, according
> > to a
> > > > > scheme that maximises the possibility for a monitor to always end
> > up at
> > > > > the same PCM (as specified in earlier emails)
> > > > >
> > > > >   * Converter node (3 nodes for Intel hardware)
> > > > >     - dynamically bound to a PCM at playback open time (regardless
> > of
> > > > > whether the PCM has a monitor or not)
> > > >
> > > > If so, we still need use converter on codec. This means we can't turn
> > > > off the power well in i915.
> > > >
> > > > To save the power, i915 suggests that if no monitor is connected,
> > > > we should not use the HDMI codec. This means open a PCM with
> > > > no pin attached will fail. Disconnecting monitor when the
> > corresponding
> > > > PCM is playback will trigger stop PCM.
> > > >
> > > > To help move to the new method smoothly, I will add a flag.
> > > > User can decide whether to use the aggressive power saving
> > > > solution or not.
> > >
> > > In  hdmi_pcm_open(), it will judge whether pin_idx is valid,
> > > if not it will return -EINVAL. So for dynamic PCM assignment,
> > > open will fail if no monitor is connected.
> > >
> > > If we want to support open on PCM without monitor, many
> > > code must be rewrited. And it seems open a PCM without
> > > monitor is not a good behavior. As Raymond said in previous
> > > email, For alt analog playback device , it return EBUSY when
> > > DAC of HP is not available. I think for HDMI audio we can
> > > have the aligned behavior? And -ENODEV may be better.
> > 
> > Libin, it's why I've been repeated asking to split the patches,
> > instead of posting a big iron patch.  Then we can test and evaluate
> > whether this part is really working in general.
> 
> Yes, I understand. :) The patches are being split. Suppose these 2 days
> patches should be ready for review.

Well, you don't have to post full patchset at all.  Rather in such a
case, a gradual test is preferred.  That is, cook this functionality
patch(es) quickly, and let people test it.  Once after it's confirmed,
start working on the rest.  It's not worth to wait for a week for each
respin because of the size and the features of of the whole patchset.


Takashi