[PATCH 3/4] ALSA: hda: Update and expose codec register procedures

[Pierre-Louis Bossart]

>>> 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.