>>> Due to ALSA-device vs ASoC-component organization differences, new >>> 'snddev_managed' argument is specified allowing for better control over >>> codec registration process. >> >> Can you maybe clarify this? The existing code to handle the different >> paths is already quite hairy (e.g. code in >> hda_codec.c:snd_hda_codec_dev_free() that does different actions >> depending on whether "codec->core.type == HDA_DEV_LEGACY) is true or >> false), so we'd need to have very clear semantics for the >> "snddev_managed". > > It's rather straightforward - ASoC does not provide you with pointer to > struct snd_card until all components are accounted for. > snd_hda_codec_device_new() in its current form needs such information > upfront though. As we want to create only as many DAIs (and other ASoC > components like links and routes) as needed, codec's ->pcm_list_head > needs to be built before codec's probing can be completed. But in order > to have hda codec to fill ->pcm_list_head for, you need to create it. > And in order to create it you need snd_card pointer which ASoC won't > give you before you complete component probing. > > Typical chicken and egg problem. And that's why additional option is > provided - it solves that problem. New capabilities are always welcome, what I am missing is how important your suggestion is for end users or OEMs. The main reason for using a DSP-based driver on a HDaudio Intel platform is when DMICs connected to the PCH, since this link cannot be handled by the legacy driver. Those sort of form factors typically have analog playback and capture only. UCM exposes only analog playback and capture. Desktops without DMICs generally rely on the legacy driver and have different sorts of problems with jack retasking and other time-consuming problems. Exposing additional DAIs in a DSP-based driver when supported by the codec is a good idea on paper, but it's far from straightforward. a) it assumes that there are indeed additional DAIs. Is this really the case on the SKL/KBL devices you are targeting? It's not on newer CML..ADL devices we've been supporting with SOF. b) it assumes that what is exposed by the codec actually does work - and the number of quirks tells us to be cautious. We routinely get reports that even Intel NUCs don't have the right quirks in the kernel... c) and then it creates new problems for the topology that may expose paths that may or may not be supported by the codec. I am not aware of any existing APIs to take down or enable a path conditionally - though it's been a problem for a very long time for SSP and DMIC enablement that are not always correctly described, and any suggestions to improve this limitation would have my full support. FWIW, in our latest SOF work we went back to handling ONE DAI with analog playback and capture and ditched the 'digital playback'. Trying to do more led us to too many issues of 'works on platform A' and 'does not work on platform B', and sometimes with different answers depending on which BIOS version is used. IMHO what's really problematic for HDaudio is the support for amplifiers located behind the HDaudio codec, for which we more often than not are missing the I2C configuration sequences. Suspend-resume is a recurring problem as well. I am not saying no for the sake of saying no, I have just never heard of anyone complain about restrictions on the number of DAIs in the HDaudio world.
