[alsa-devel] [PATCH 2/2] [RFC] ALSA: hda: hdmi - preserve non-MST PCM routing for Intel platforms

[Takashi Iwai]

On Fri, 29 Nov 2019 15:47:11 +0100,
Kai Vehmanen wrote:
> 
> Hi Takashi, Nikil and others,
> 
> On Fri, 29 Nov 2019, Kai Vehmanen wrote:
> > This difference leads to some subtle differences in hdmi_find_pcm_slot()
> > with regards to how non-MST monitors are assigned to PCMs.
> > This patch restores the original behaviour on Intel platforms while
> > keeping the new allocation policy on other platforms.
> 
> hmm, there seems a couple of more issues. The first patch is a clear bug 
> that leads to segfault with SOF+patch_hdmi on some platforms (pipe B used
> for single monitor HDMI case -> dev_id=1 -> non-existant pcm selected
> and eventual kernel oops).
> 
> This second patch is however trickier. Nikhil your patch changed the 
> default allocation a bit, so the routing might be difference also with 
> snd-hda-intel (i.e. not SOF) for existing platforms and this may surprise 
> users.

Well, but the allocation itself is dynamic for DP-MST, even on Intel,
so user can't expect the completely persistent index assignment.
That's the reason I took Nikhil's patch (even I suggested to simplify
in that way).

We had a trick to assign the primary index.  It still works, right?
That should be the only concern.

> Digging deeper, we seem to have a slight semantics difference in how
> intel_pin_eld_notify() and generic_acomp_pin_eld_notify() handle
> the third pipe/dev_id parameter.

This is a platform-specific part, and on Intel, the assumption has
been that pipe is equivalent with dev_id.  If this changed, of course,
we must reconsider the whole picture.

For generic_acomp_pin_eld_notify(), it's gfx-driver specific, too.
And currently dev_id = -1 in AMDGPU, so we don't think too much about
the behavior compatibility.

> Any thoughts how to solve? I first I thought making separate functions
> for hdmi_find_pcm_slot() and allow platforms to define an alternative
> implementation, but in this RFC patch I opted for a simpler quirk in the 
> function. This is becoming fairly messy I must say -- the amount of 
> code commentary needed is a good indication some simplifaction would
> be in order.

Yeah, that's a bit messy.  The only expectation is the primary slot
assignment -- i.e. the case only one monitor is connected.  As long as
this behavior is kept, I don't think any big problem with the dynamic
assignment.

> PS I did not have time to fully test the RFC patch, so this is just
>    for discussion now...

Since the assignment should work with your patch somehow, I already
applied it.  Let's do fine tune-up during 5.5 rc cycles, if any.


thanks,

Takashi