From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>,
Dominik Brodowski <linux@dominikbrodowski.net>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
Mark Brown <broonie@kernel.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Takashi Iwai <tiwai@suse.com>
Subject: Re: ACPI REV override for Dell XPS 13 9343
Date: Tue, 14 Jun 2022 11:51:01 -0500 [thread overview]
Message-ID: <398e4885-736c-d9a9-a18d-34f69f2b63ca@linux.intel.com> (raw)
In-Reply-To: <fb13198a-3d38-4304-6212-966561725d55@intel.com>
>>> It's been a while since catpt-driver [1] has been introduced to provide
>>> full support for Broadwell (BDW) machines with Intel DSP. For BDW, audio
>>> devices can make use of DSP only in I2S mode. In 2015 Rafael and Dominik
>>> provided quirk [2] for Dell XPS 13 9343. Given the description:
>>>
>>> _For example, based on what ACPI exports as the supported revision, Dell
>>> XPS 13 (2015) configures its audio device to either work in HDA mode or
>>> in I2S mode, where the former is supposed to be used on Linux until the
>>> latter is fully supported (in the kernel as well as in user space)._
>>>
>>> It's clear that such configuration was not fully supported back then. I
>>> believe now it is. Perhaps it is time to let the quirk in mention go? By
>>> that I mean just the relevant entry, not the ACPI_REV_OVERRIDE_POSSIBLE
>>> functionality as a whole.
>>
>> This should be a distribution or power-user decision to enable the I2S
>> version IMHO.
>>
>> There is nothing new in terms of functionality with the I2S version, so
>> limited added-value that doesn't offset the added risk due to the
>> dependencies on mixer settings that may or may not be installed (UCM,
>> etc).
>>
>> If it ain't broke don't fix it.
to clarify: the HDaudio mode works just fine, there are currently zero
issues or missing functionality reported by users.
> Not much of a fan of the last statement. I believe challenging status
> quo is the right thing to do. We do not want to bloat the kernel with
> unnecessary quirks.
>
> The broadwell-rt286 UCM is part of alsa-ucm-conf repo for years now.
The hardware supports two modes (HDaudio and DSP + I2S), the former has
been in use without any issues for years.
Even if you make DSP + I2S the default, you've got to leave HDaudio as a
fallback, so there would be no change at the kernel level.
It' very very hard to remove stuff, and in this case there is limited
evidence that distributions use the DSP + I2S mode. You could deprecate
the ACPI_OVERRIDE but you've got to leave time for distributions to switch.
Challenging the status quo is great, but let's keep downstream in mind,
shall we?
The only option we removed was Medfield several years ago, but we had
clear evidence that no one would be affected by such a change in the
upstream kernel.
next prev parent reply other threads:[~2022-06-14 16:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 10:53 ACPI REV override for Dell XPS 13 9343 Cezary Rojewski
2022-06-13 13:05 ` Pierre-Louis Bossart
2022-06-14 16:26 ` Cezary Rojewski
2022-06-14 16:51 ` Pierre-Louis Bossart [this message]
2022-06-14 17:03 ` Mark Brown
2022-06-15 8:29 ` Cezary Rojewski
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=398e4885-736c-d9a9-a18d-34f69f2b63ca@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=hdegoede@redhat.com \
--cc=linux@dominikbrodowski.net \
--cc=rafael.j.wysocki@intel.com \
--cc=tiwai@suse.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox