On 16/07/2023 13:49, Takashi Iwai wrote:
On Thu, 13 Jul 2023 18:29:53 +0200,
David Xu wrote:
As the comments added in commit 4d4c4bff4f8ed79d95e05 ("ALSA: hda:
cs35l41: Clarify support for CSC3551 without _DSD Properties"), CSC3551
requires a valid _DSD to work and the current implementation just
fails when no _DSD can be found for CSC3551. However it is a fact
that many OEMs hardcoded the configurations needed by CSC3551 into their
proprietary software for various 2022 and later laptop models,
and this makes the Linux installations on these models cannot make
any speaker sound. Meanwhile, at this point of time, we see no hope
that these OEMs would ever fix this problem via a BIOS update.
To address the problem, this patch series contains two patches:
Patch 1 for cs35l41 hda driver: a fixup mechanism is introduced that
when the driver found there is no valid _DSD that contains the
configurations, a fixup function would try to find a fixup entry that
contains a proper cs35l41 configuration from a pre-defined fixup table
by matching the CSC3551 ACPI _SUB id. If found, the fixup function
would apply the cs35l41 configurations retrived from the entry.
In this patch the fixup table only contains some entries for three
Lenovo laptop models: namely 16IAH7, 16IAX7 and 16ARHA7. However
as is known, several other laptop models from ASUS and HP also suffer
from this no valid _DSD problem and could have it addressed with this
fixup mechanism when proper fixup entries are inserted.
Patch 2 for realtek hda driver: add quirks for Lenovo 16IAH7, 16IAX7
and 16ARHA7 so that cs35l41 playback hook could be registered. Please
note that for these quirks to work patch 1 has to be applied.
Thanks for the patches.
I've seen the lots of pains with CS35L41 codec stuff on the recent
machines. But, first of all, it still needs to be agreed by Cirrus
people whether this approach is acceptable. Judging from the current
situation, such workaround appears inevitable, but we need a
consensus.
So, Cirrus people, please check this.
Also, some ideas about the current patch set:
- Do we need yet another listing and check of each ID in another
place? The existing entry in the SSID quirk table is already unique
enough to identify which configuration is taken, I suppose.
- The quirk entries can be gathered in patch_realtek.c, and the hw_cfg
and other items are overwritten in cs35l41_no_acpi_dsd() when no
_DSD is found. In that way, we can avoid fixing two places for each
update.
- The workaround is a workaround, and it's fundamentally dangerous.
We should warn it in a kernel message.
Takashi
Hi David, Takashi,
We're looking into supporting some of these older devices at the moment,
and have a patch chain in development at the moment.
The approach we've taken is a lot closer to the one taken by the github
Luke links through to elsewhere in this chain, which we think might be a
cleaner approach. We do have concerns about the current approach of
identifying the SPI device though, as we've seen "spi1" become "spi2" as
additional devices become supported in the kernel and more SPI
controllers come into use. We'll look into this more and hopefully get
a patch chain up in the coming weeks.
This patch chain looks like it might also be missing support for
different boost configurations.
I wouldn't recommend this patch be merged.
Thanks,
Stu
