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
