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

[Takashi Iwai]

On Wed, 11 Nov 2015 09:33:18 +0100,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai at suse.de]
> > Sent: Wednesday, November 11, 2015 4:27 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 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.
> 
> Get it. I will submit the patches if any is ready.
> 
> BTW: for the DP MST audio, can we put the patches into a new branch first
> and wait all patches for MST audio are ready and mature, and then move 
> the patches to master branch?

On my tree?  It's fine, but it means that the patches aren't tested by
linux-next.  Or if you have your own git tree and it's published, you
can keep the changes there, instead.


Takashi