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

From: Hans de Goede <hdegoede@redhat.com>
To: Mark Brown <broonie@kernel.org>,
	"Rojewski, Cezary" <cezary.rojewski@intel.com>
Cc: "tiwai@suse.de" <tiwai@suse.de>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices
Date: Fri, 13 Nov 2020 18:06:09 +0100	[thread overview]
Message-ID: <2cf7075b-bd51-21a5-2058-3a98e6c488a7@redhat.com> (raw)
In-Reply-To: <20201113164946.GD4828@sirena.org.uk>

Hi,

On 11/13/20 5:49 PM, Mark Brown wrote:
> On Fri, Nov 13, 2020 at 01:06:48PM +0000, Rojewski, Cezary wrote:
> 
>> 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.
> 
> ...
> 
>> 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.
> 
> My feeling here was that this is helping with this goal in that it's not
> changing the defaults but is rather pushing the decision making process
> from build time to runtime.  This means that distributions are able to
> ship the preferred implementations for all the platforms without causing
> any issues for the hopefully small set of users who need or want to work
> on a different firmware, if they've been doing something like sticking
> with an alternative firmware for old users since things were working
> they'll be able to smoothly transition over to the current recommended
> default, eg leaving old users on the old firmware by default.  That's a
> bit of a niche use case but then hopefully all use cases for selecting a
> non-default firmware are niche.
> 
> It also means that people don't have to think about this so much at
> build time, they can just turn everything on and not worry they'll cause
> problems for people using the binary and still get the recommended
> runtime behaviour by default unless the user actively does something

Exactly. As Pierre-Louis mentions the Intel team does not have most
of the affected hardware. Since I've been working on making BYT and CHT
based devices work better with Linux as a side project for the last
couple of years I have been buying these kinda devices 2nd hand when ever
I can get one cheap and I've built a big collection of these (one might
say this has gotten out of hand a bit) see here:

https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/x86-tablet-info
https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/x86-codec-info

For my device collection (mostly the first link).

As Pierre-Louis mentioned I've already been working with him on getting
ready to move everything BYT/CHT related over to SOF. I've already been
testing SOF on various devices with mostly ok results so far.
But this is a process not a switch which we can simply throw.

So I'm all in favor of this patch-set. With some luck we can switch the
BYT/CHT default to SOF in Fedora for F34 beta (*), but doing that really
sorta hinges on this patch-set so that users can easily try the old
driver, both as a workaround for issues and to check if the problem
is caused by the switch to SOF.

Talking about doing this for Fedora 34, I think that switching the
default there is a good idea (and I can make this happen) what do
others think about doing this?

Regards,

Hans