On Wed, 11 Nov 2015 09:33:18 +0100, Yang, Libin wrote:
Hi Takashi,
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, November 11, 2015 4:27 PM To: Yang, Libin Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@linux.ie'; 'tanuk@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@suse.de] Sent: Wednesday, November 11, 2015 4:06 PM To: Yang, Libin Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau';
'airlied@linux.ie';
'tanuk@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@linux.ie; tanuk@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@canonical.com]
> Sent: Tuesday, November 10, 2015 3:45 PM > To: Yang, Libin; Takashi Iwai > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@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@canonical.com] > >> Sent: Thursday, November 05, 2015 5:07 PM > >> To: Yang, Libin; Takashi Iwai > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie;
tanuk@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
> > 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