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
[...]
- 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:
- 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?
- 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