Re: [alsa-devel] [RFC PATCH 0/7] adapt SOF to use snd-hda-codec-hdmi

From: Takashi Iwai <tiwai@suse.de>
To: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: libin.yang@intel.com, alsa-devel@alsa-project.org,
	pierre-louis.bossart@linux.intel.com
Subject: Re: [alsa-devel] [RFC PATCH 0/7] adapt SOF to use snd-hda-codec-hdmi
Date: Tue, 03 Sep 2019 17:11:29 +0200	[thread overview]
Message-ID: <s5hv9u9tnxa.wl-tiwai@suse.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1909031656490.16459@zeliteleevi>

On Tue, 03 Sep 2019 16:18:11 +0200,
Kai Vehmanen wrote:
> 
> Hi,
> 
> On Thu, 29 Aug 2019, Takashi Iwai wrote:
> 
> >> here's a RFC patch series that adapts SOF (and one example machine
> >> driver) to use snd-hda-codec-hdmi (patch_hdmi.c) codec driver
> >> instead of hdac_hdmi (soc/codecs/hdac_hdmi.c). The primary goal
> [...]
> >> 2) Can we drop hdac_hdmi and its support from machine drivers, or
> >>    do we need to make it optional and keep it around?
> > 
> > IMO, the only and the most important point is whether it works as-is
> > without changing the existing user-space, or exactly what scenario
> > would be broken.  If the breakage is significant, we may introduce a
> > Kconfig, as you suggested.
> > 
> > I don't think the mixer contents change are problematic.  In the case
> > of HDMI/DP, it's mostly read-only for fetching ELD or jack state.
> 
> I've been now continuing testing with different combinations of 
> kernel/user-space and the two main problematic areas are:
> 
> 1) systems with UCM defined with hdac-hdmi style controls
> 
> -> as the card name will not change, the UCM usage will fail 
> when kernel is updated to use different HDMI codec driver
> 
> On some systems this is manageable as e.g. pulseaudio will fallback to 
> legacy non-UCM path and e.g. HDMI/DP audio keeps working. But, but, this 
> may be problematic if UCM is needed for other functionality on these 
> systems.

Just out of curiosity: which systems are with such UCM profiles?
Chromebooks?

> 2) machine drivers shared with SST/SOF
> 
> Doing the HDMI codec change for old platforms handled with SST driver 
> looks difficult to do, so we probably need to keep hdac-hdmi around for 
> SST usage. That does mean machine drivers that are shared, need to support 
> both options.
> 
> Combining 1+2, it would seem safer to have a opt-in/opt-out possibility 
> via Kconfig. I'm preparing a patchset for this -- let's see how it will 
> look.

Agreed, some Kconfig is a safer option for now.

thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel