On 2020-11-17 11:53 PM, Pierre-Louis Bossart wrote: > On 11/17/20 4:13 PM, Rojewski, Cezary wrote: >> On 2020-11-17 3:04 PM, Takashi Iwai wrote: ... >>> I guess Cezary mean the modprobe blacklist? This was used in the >>> early stage of ASoC Skylake driver development, but in the end, it's >>> more cumbersome because user needs to change multiple places. The >>> single module parameter was easier to handle. >>> >> >> Thanks for joining the discussion, Takashi. >> >> If the switch of solution for atom-based products is imminent, why add >> code which becomes redundant soon after? > > To be clear: there is *no plan* to *remove* the Atom/sst code any time > 'soon', only to *deprecate* it. > > In the best case distributions would transition in 2021. Some distros > are faster than others, neither you nor I have any control over this. > > Removing code from the kernel is not something we can do unless there is > demonstrated evidence that the number of impacted users is close to zero > and distributions no longer support that code. The case of Baytrail > legacy is telling, you removed it earlier this Fall but after a > recommended alternative was provided for more than 3 years. > > Again, there is no planned 'switch' but a gradual transition, and that > patchset helps with the transition. Hmm, then maybe I misunderstood Hans. Given his feedback it seemed like Fedora is about to switch to SOF right now. Indeed, before I've sent patches removing Baytrail, basically every support-team had been asked about its usage and the answers were negative. /atom/ was covering basically every case anyway like you pointed out so /baytrail/ solution felt more like a duplication. As SOF is the desired solution for atom-based products, I can see the need for some sort of selection mechanism. The same cannot be said for hsw/bdw though. Let's leave catpt out this, shall we? Czarek
