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
