All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Rojewski, Cezary" <cezary.rojewski@intel.com>
Cc: "tiwai@suse.de" <tiwai@suse.de>,
	Hans de Goede <hdegoede@redhat.com>,
	"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 16:49:46 +0000	[thread overview]
Message-ID: <20201113164946.GD4828@sirena.org.uk> (raw)
In-Reply-To: <0a0854d1ddaf4f9b81ef5569a7d501a5@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

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.

At any rate I'm not clear that I see this actively causing problems.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-11-13 16:51 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 22:38 [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 01/14] ASoC: Intel: broadwell: add missing pm_ops Pierre-Louis Bossart
2020-11-13 11:17   ` Rojewski, Cezary
2020-11-12 22:38 ` [PATCH 02/14] ASoC: Intel: bdw-rt5677: " Pierre-Louis Bossart
2020-11-13 11:19   ` Rojewski, Cezary
2020-11-12 22:38 ` [PATCH 03/14] ALSA: hda: intel-dsp-config: add helper for ACPI DSP driver selection Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 04/14] ASoC: soc-acpi: add helper to identify parent driver Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 05/14] ASoC: Intel: boards: byt/cht: set card and driver name at run time Pierre-Louis Bossart
2021-04-25 18:13   ` youling257
2021-04-26 15:12     ` Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 06/14] ASoC: Intel: byt/cht: set pm ops dynamically Pierre-Louis Bossart
2020-11-17 17:18   ` Mark Brown
2020-11-17 17:39     ` Pierre-Louis Bossart
2020-11-18 13:31       ` Mark Brown
2020-11-12 22:38 ` [PATCH 07/14] ASoC: SOF: acpi: add dynamic selection of DSP driver Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 08/14] ASoC: Intel: Atom: " Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 09/14] ASoC: SOF: Intel: allow for coexistence between SOF and Atom/SST drivers Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 10/14] ALSA: hda: intel-dsp-config: add Broadwell ACPI DSP driver selection Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 11/14] ASoC: Intel: broadwell: set card and driver name dynamically Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 12/14] ASoC: Intel: catpt: add dynamic selection of DSP driver Pierre-Louis Bossart
2020-11-12 22:38 ` [PATCH 13/14] ASoC: SOF: Intel: allow for coexistence between SOF and catpt drivers Pierre-Louis Bossart
2020-11-19 14:06   ` Mark Brown
2020-11-19 17:52     ` Pierre-Louis Bossart
2020-11-19 18:25       ` Mark Brown
2020-11-12 22:38 ` [PATCH 14/14] ALSA: hda: intel-dsp-config: ignore dsp_driver parameter for PCI legacy devices Pierre-Louis Bossart
2020-11-12 23:04 ` [PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices Rojewski, Cezary
2020-11-13 13:06 ` Rojewski, Cezary
2020-11-13 14:40   ` Pierre-Louis Bossart
2020-11-13 16:49   ` Mark Brown [this message]
2020-11-13 17:06     ` Hans de Goede
2020-11-16 15:39       ` Rojewski, Cezary
2020-11-16 17:47         ` Pierre-Louis Bossart
2020-11-17 14:04           ` Takashi Iwai
2020-11-17 17:31             ` Mark Brown
2020-11-17 17:46               ` Takashi Iwai
2020-11-17 22:13             ` Rojewski, Cezary
2020-11-17 22:53               ` Pierre-Louis Bossart
2020-11-18 20:15                 ` Rojewski, Cezary
2020-11-18 20:25                   ` Pierre-Louis Bossart
2020-11-20 15:40                     ` Rojewski, Cezary
2020-11-20 16:48                       ` Mark Brown
2020-11-20 17:10                         ` Rojewski, Cezary
2020-11-20 18:06                           ` Mark Brown
2020-11-20 21:02                             ` Rojewski, Cezary
2020-11-23 17:35                               ` Mark Brown
2020-11-24 11:56                                 ` Rojewski, Cezary
2020-11-24 14:01                                   ` Mark Brown
2020-11-24 14:15                                     ` Takashi Iwai
2020-11-24 16:07                                       ` Rojewski, Cezary
2020-11-24 16:14                                         ` Mark Brown
2020-11-24 16:14                                         ` Takashi Iwai
2020-11-24 16:12                                       ` Mark Brown
2020-11-18  7:49               ` Takashi Iwai
2020-11-18 20:59                 ` Rojewski, Cezary
2020-11-20 21:29 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201113164946.GD4828@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=cezary.rojewski@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.