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

[Kai Vehmanen]

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.

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.

Br, Kai