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

Rojewski, Cezary cezary.rojewski at intel.com
Wed Nov 18 21:15:56 CET 2020


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



More information about the Alsa-devel mailing list