Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 16 Jul 2023 14:49:18 +0200
Message-ID: <87zg3waunl.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     David Xu <xuwd1@hotmail.com>
Cc:     James Schulman <james.schulman@cirrus.com>,
        David Rhodes <david.rhodes@cirrus.com>,
        Richard Fitzgerald <rf@opensource.cirrus.com>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>,
        "Luke D. Jones" <luke@ljones.dev>,
        Stefan Binding <sbinding@opensource.cirrus.com>,
        Andy Chi <andy.chi@canonical.com>,
        Tim Crawford <tcrawford@system76.com>,
        Philipp Jungkamp <p.jungkamp@gmx.net>,
        Kacper =?ISO-8859-2?Q?Michaj=B3ow?= <kasper93@gmail.com>,
        Matthew Anderson <ruinairas1992@gmail.com>,
        Yuchi Yang <yangyuchi66@gmail.com>,
        Yang Yingliang <yangyingliang@huawei.com>,
        alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Fix CSC3551 speaker sound problem for machines without a valid ACPI _DSD
In-Reply-To: <SY4P282MB18352D4FD343A2E8290EA9BEE037A@SY4P282MB1835.AUSP282.PROD.OUTLOOK.COM>
References: <SY4P282MB18352D4FD343A2E8290EA9BEE037A@SY4P282MB1835.AUSP282.PROD.OUTLOOK.COM>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

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