[SRU][Focal][PATCH 0/9] alsa/hdmi: support nvidia mst hdmi/dp audio

[Stefan Bader]

On 12.08.20 07:58, Hui Wang wrote:
> BugLink: https://bugs.launchpad.net/bugs/1867704
> 
> This patchset will introduce a big change on hda_jack and hda_hdmi,
> So I sent the patcheset to oem-b 4 months ago. After 4 months of running
> oem-b kernel, there is no any regression reported on this patchset,
> now I am backporting the patchset to our focal kernel since our oem
> project is waiting for the patchset to be landed to ubuntu 5.4 kernel
> ASAP.
> 
> This patchset are already merged to mainline kernel 5.5-rc and 5.6-rc,
> so there is no need to send the patchset to oem-5.6 or groovy kernel.
> 
> [Impact]
> On some LENOVO I+N machines, when setting the graphic mode to discrete,
> The dp/hdmi audio on the Docking Gen2 can't work with this machine +
> LENOVO Docking Gen2, users can't find the hdmi audio entry in the
> gnome-sound-setting.
> 
> [Fix]
> Nvidia developer submit the mst audio support to 5.5-rcN and 5.6-RC1,
> those patches could fix this issue.
> 
> [Test Case]
> set the machien to discrete, plug the dock gen2 to it, then boot, after
> booting, plug hdmi or dp to dock gen2, the hdmi or dp audio works.
> 
> test other machines without Nvidia graphic or without gen2, their hdmi/dp
> audio still work, and check other output/input devices like headphone,
> microphone, they all worked as well as before.
> 
> 
> [Regression Risk]
> one regression possibility is the audio jacks (including analogue and hdmi)
> can't work anymore, that means after users plug a headphone, headset, hdmi
> monitor or microphone to the audio jacks or hdmi connectors, the audio
> driver can't detect the plugging event.
> 
> But regression's possibility is very low:
>  - this patchset was already applied to oem-b kernel for 4 months, and
>    oem projects didn't report any regression on the patchset
>  - I tested the testing focal kernel with this patchset on many machines,
>    includes a dell hda audio machine, a dell dmic  machine, a Lenovo I+N
>    hda audio machine, a lenovo I+N dmic machine, a lenovo I hda audio
>    machine, a lenovo amd hda audio machine. The audio on them all worked
>    as well as before.
> 
> 
> Kai Vehmanen (3):
>   ALSA: hda: hdmi - fix regression in connect list handling
>   ALSA: hda: hdmi - fix kernel oops caused by invalid PCM idx
>   ALSA: hda: hdmi - preserve non-MST PCM routing for Intel platforms
> 
> Nikhil Mahale (5):
>   ALSA: hda - Rename snd_hda_pin_sense to snd_hda_jack_pin_sense
>   ALSA: hda - Add DP-MST jack support
>   ALSA: hda - Add DP-MST support for non-acomp codecs
>   ALSA: hda - Add DP-MST support for NVIDIA codecs
>   ALSA: hda - Fix DP-MST support for NVIDIA codecs
> 
> Takashi Iwai (1):
>   ALSA: hda: hdmi - Keep old slot assignment behavior for Intel
>     platforms
> 
>  sound/pci/hda/hda_jack.c   | 151 ++++++++++-----
>  sound/pci/hda/hda_jack.h   | 107 +++++++++--
>  sound/pci/hda/patch_hdmi.c | 384 ++++++++++++++++++++++++-------------
>  3 files changed, 455 insertions(+), 187 deletions(-)
> 
Seems like at least some wider range testing has happened. Just double checking,
when I am looking for DP-MST in the upstream kernel, there is one following your
patchset:

Commit db8454023b7f9ca6d341cc83ce033a1f0e33d9c3
Author: Takashi Iwai <tiwai at suse.de>
Date:   Thu Feb 6 17:28:02 2020 +0100

    ALSA: hda/hdmi: Don't use standard hda_jack for generic HDMI jacks

    The current HDMI codec driver code manages the jack detection in two
    different ways: for Intel codecs with audio component, the driver
    creates snd_jack objects by itself while the standard hda_jack stuff
    is used for the rest.  This was basically because the audio component
    doesn't need the pin sense reading and the unsol event handling, hence
    it just needs to report the corresponding jacks directly.

    It was a bit messy but not too messy until the driver got DP-MST
    support for Nvidia that re-uses the part of dyn_pcm_assign feature
    while keeping the pin sense and the unsol event handling.  Now, for
    DP-MST, we use hda_jack for pin sensing and unsol events but use the
    own snd_jack objects.  Meanwhile for non-DP-MST, hda_jack is used for
    pin sense and unsol events, and the jacks are bound on hda_jack.

    Moreover, there is a polling mode support where the unsol event isn't
    used.  For those, we also have special handling.

Could that be something that might be an issue?

-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20200812/af0a66a7/attachment.sig>