On Wed, 11 Nov 2015 09:33:18 +0100, Yang, Libin wrote: > > Hi Takashi, > > > -----Original Message----- > > From: Takashi Iwai [mailto:tiwai@xxxxxxx] > > Sent: Wednesday, November 11, 2015 4:27 PM > > To: Yang, Libin > > Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; 'airlied@xxxxxxxx'; > > 'tanuk@xxxxxx'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu, > > Han; Nikula, Jani > > Subject: Re: 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@xxxxxxx] > > > > Sent: Wednesday, November 11, 2015 4:06 PM > > > > To: Yang, Libin > > > > Cc: 'David Henningsson'; Lin, Mengdong; 'Raymond Yau'; > > 'airlied@xxxxxxxx'; > > > > 'tanuk@xxxxxx'; 'ALSA Development Mailing List'; Girdwood, Liam R; Lu, > > > > Han; Nikula, Jani > > > > Subject: Re: 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@xxxxxxxx; tanuk@xxxxxx; > > ALSA > > > > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani > > > > > > Subject: RE: DP1.2 MST audio support discussion > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: David Henningsson > > > > [mailto:david.henningsson@xxxxxxxxxxxxx] > > > > > > > Sent: Tuesday, November 10, 2015 3:45 PM > > > > > > > To: Yang, Libin; Takashi Iwai > > > > > > > Cc: Lin, Mengdong; Raymond Yau; airlied@xxxxxxxx; tanuk@xxxxxx; > > > > ALSA > > > > > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, > > Jani > > > > > > > Subject: Re: 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@xxxxxxxxxxxxx] > > > > > > > >> Sent: Thursday, November 05, 2015 5:07 PM > > > > > > > >> To: Yang, Libin; Takashi Iwai > > > > > > > >> Cc: Lin, Mengdong; Raymond Yau; airlied@xxxxxxxx; > > tanuk@xxxxxx; > > > > > > ALSA > > > > > > > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, > > > > Jani > > > > > > > >> Subject: Re: 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
