RE: [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices

["Rojewski, Cezary" <cezary.rojewski@intel.com>]

On 2020-11-13 12:04 AM, Rojewski, Cezary wrote:
> On 2020-11-12 11:38 PM, Pierre-Louis Bossart wrote:
>> The module snd-intel-dspcfg, suggested by Jaroslav last year,
>> currently provide the means to select a PCI driver at run-time, based
>> on quirks, recommendations or user selection via a kernel
>> parameter. This capability removed a lot of confusions in
>> distributions and removed the need for recompilations to select legacy
>> HDaudio, SST or SOF drivers.
>>
>> This patchset extends the concept to ACPI devices. This was driven by
>> the desire to at some point deprecate the Atom/SST driver for Baytrail
>> and Cherrytrail, which is no longer maintained by Intel. By having the
>> SOF driver enabled by distributions for Baytrail/Cherrytrail, we can
>> enable more end-user tests and make the transition easier for
>> distributions (likely in 2021 at this point).
>>
>> This patchset provides the same solution for Broadwell, mainly to have
>> a single build for all Intel platforms. SOF on Broadwell remains an
>> option not recommended for distributions, as long as the 'catpt'
>> driver is maintained there is no burning desire to make SOF the
>> default on the three Broadwell-based platforms with the DSP
>> enabled.
>>
> 
> Hello,
> 
> Don't understand why I was omitted in CC for catpt-related patches.
> 
> I'll try to do proper review tomorrow as it's late here but for
> starters: why do we need any intel-dsp-config changes for non-HDA
> platforms, what's the technical reason behind these?
> 
> Czarek
> 

As almost all of the patches share the concerns, decided to provide
entire output here so it's easier to navigate later on.

For a very long time upstream was filled with "flavors" of drivers for
Intel solutions. Having three available for BYT is a very good example
of that. The division of what goes where wasn't exactly explicit either.
This all leads to confusion - while community and users may feel
confused about what's recommended and what they should actually be
using, surprisingly (unsurprisingly?) developers were too.

Latest changes provided by Intel employees were addressing exactly that.
Removal of obsolete and redundant code. Together with fixing several
issues that were bothering users of older solutions, net gain was:
reduction of confusion and complexity factors.

Patchset presented here goes directly against that goal. We, Intel
developers, are tasked with providing reliable, working solutions
exposing best possible experience for our customers when dealing with
our products. And thus solutions provided are called recommended. We
don't deal with flavors and try-it-out-on-your-own-risk.

Moreover, intel-dsp-config module was created to address completely
different problem - problem of selecting correct HDA driver given the
circumstances. This is true as one cannot always rely on DSP-capability
bit being enabled when HDA-legacy is meant to be the default solution on
given platform. In future maybe we should revisit that subject once
again as perhaps even the existing solution isn't resolving the problem
completely.

Neither HSW/BDW nor atom-based platforms are HDA-based. Those are ACPI
devices and you know upfront what we're dealing with. There is no
DSP-capability bit to check for to know whether we're dealing with
legacy solution or not. As these are explicit configurations, one needs
not to bother with additional magic enums.

As long as Intel recommendation stays with /atom/ for atom-based
products, so should linux kernel.
Same for hsw/bdw - Intel recommends closed firmware solution and thus
this should remain as the only available choice - leaving no place for
confusion.

Once and if SOF is ready to support all available atom configuration, it
should deprecate and replace it with the same fashion catpt replaced its
predecessor. Until that moment, things should remain as they are. No
additional quirks or magic, just plain simple ACPI-ID based selection.

Users that are making use of optional and opportunistic changes
especially in regard to selecting not-recommended choices are
experienced enough to rebuild their kernel and merge out-of-tree changes
and they are free to do so if they want to. Upstream kernel, however, is
not place for keeping such code.

Czarek