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

[Cezary Rojewski]

On 2022-02-08 6:46 PM, Pierre-Louis Bossart wrote:

> New capabilities are always welcome, what I am missing is how important
> your suggestion is for end users or OEMs.


Users won't notice and why would we like them to notice? The intended 
behavior is 1:1 with hda legacy one.

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


I believe we're all aware why and when DSP-drivers are chosen over HDA 
legacy driver. That's orthogonal to the current subject.

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


The outcome is reduction in number of DAIs exposed for basically all 
codecs except for HDMIs as DSP-based solutions are hardcoding 3-DAIs. 
Here, the intended behavior is to be 1:1 with hda legacy behavior, not 
hardcoding.

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


It does not _assume_, it _reads_. The outcome is reduction of DAIs 
exposed rather than hardcoding Analog/Alt Analog/Digital endpoints what 
is currently the case.

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


Patches just expose functions. Logic stays the same. As it is 
sound/pci/hda code we're talking about, that code is quirk-friendly - it 
contains several "patches" and quirks already.

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


The default for topology is to expose just single analog endpoint as 
majority of codecs expose nothing else. Moreover, having just 1 FE 
defined in topology can be used to limit the usecases where we know 
codec says it exposes more but in fact these endpoints aren't 
functional. For specific codecs that expose more, a specific topology 
can be provided just like it's done for any DSP-driver today.

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


I believe our goals align. Rather than hardcoding Analog/Alt 
Analog/Digital endpoints as it's done currently, when codec most of the 
time do not have them working anyway, rely on behavior found in 
sound/hda and sound/pci/hda. If there are some problems there it's 
win:win for us and legacy driver. Fix one spot, have both drivers happy.


Regards,
Czarek