[alsa-devel] [RFC PATCH 3/4] ASoC: hdac_hdmi: refine hdmi jacks

[Takashi Iwai]

On Tue, 25 Jun 2019 13:41:58 +0200,
Hui Wang wrote:
> 
> 
> On 2019/6/25 下午7:05, Takashi Iwai wrote:
> > On Tue, 25 Jun 2019 08:02:45 +0200,
> > Yang, Libin wrote:
> >>> Sorry for a long delay for the hdmi jacks. I was busy on another critical issue
> >>> last 2 weeks. I have worked out the UCM configuration files. Please check the
> >>> attachment. It is a long file, so I use the attachment instead of the patch mode.
> >>> Based on my test, it works well. Could you please help review if the
> >>> configuration file is OK or not. I will do more test on the meantime, including
> >>> DPMST and NON-DPMST.
> >> With some more tests on the new hdmi jack with UCM configuration, I found
> >> that the kernel patch can always notify the jack hotplug event to userspace
> >> correctly. However, the userspace can't set the amixer correctly based on
> >> the UCM configurations sometimes.
> >>
> >> Here is the details:
> >> There are 3 PCMs on Intel platforms. Let's call them pcm1, pcm2, pcm3.
> >> And there are 3 pins (pin5, pin6, pin7). For DPMST, and each pin has 3 ports:
> >> port0, port1, port2.
> >>
> >> For non-DPMST, we can set pin5 <=> pcm1, pin6 <=> pcm2, pin7 <=> pcm3.
> >> This can always work.
> >>
> >> For DPMST, as there are 9 ports using 3 pcms. So we should assign
> >> 1 pcm to 3 ports. For example, pin5-port0, pin6-port1 and pin7-port2
> >> are using pcm1;  pin5-port1, pin6-port2 and pin7-port0 are using
> >> pcm2; pin5-port2; pin6-port3 and pin7-port1 are using pcm3.
> >> In this setting, we should setting the ConflictingDevice in UCM.
> >> For example, pin5-port0 is conflicting with pin6-port1 and pin7-port2.
> >> Hui and I found if we set one device conflicting with 2 devices, the
> >> amixer setting will be wrong and it will not following UCM configuration
> >> setting when we are hotplugging the monitors.
> > How wrong would it behave?  Only one of them is done?
> 
> Yes, only the 1st conflicting device is handled.
> 
> for example:
> 
> pin5-port0 has two conflicting devices: pin6-port1 and pin7-port2,
> 
> When pin5-port0 is active in the pulseaudio, I can see the
> pin6-port1.DisableSequece and pin7-port2.DisableSequence are called
> according to pulseaudio's log, but it looks like the commands only in
> the 1st device (pin6-port1.DisableSequence) are executed.
> 
> To call conflicting devices' disablesequence, the pulseaudio will call
> snd_use_case_set(ucm->ucm_mgr, "_disdev", dev_name) twice, but only
> the 1st time calling takes effect.

If you reached at that point, you can continue tracking in alsa-lib :)
If it's some weird behavior in set_device(), it must be either the
list management failure in UCM or execute_sequence() misses
something.


thanks,

Takashi