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@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
