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

Takashi Iwai tiwai at suse.de
Tue Sep 3 17:11:29 CEST 2019


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


More information about the Alsa-devel mailing list