On Mon, 17 Jul 2023 13:48:28 +0100, Stuart Henderson wrote:
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
Hi Stuart,
Thank you for replying. I am looking forward to your work for fixing this problem and hopefully I could see it in the following weeks. In addtion I'd like to justify this lack of support for boost configurations as without a valid _DSD, it is nearly impossible for us users to know the correct and safe configuartion for internal boosting. The current situation is that without this boosting config, we indeed get a quite low speaker sound. It would be much appreciated if you could also solve this problem.
Regards,
David