[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SY4P282MB18354B658F2FFE36E6FED411E03BA@SY4P282MB1835.AUSP282.PROD.OUTLOOK.COM>
Date: Mon, 17 Jul 2023 22:14:17 +0800
From: David Xu <xuwd1@...mail.com>
To: tiwai@...e.de
Cc: alsa-devel@...a-project.org, andy.chi@...onical.com,
david.rhodes@...rus.com, james.schulman@...rus.com,
kasper93@...il.com, linux-kernel@...r.kernel.org, luke@...nes.dev,
p.jungkamp@....net, patches@...nsource.cirrus.com, perex@...ex.cz,
rf@...nsource.cirrus.com, ruinairas1992@...il.com,
sbinding@...nsource.cirrus.com, tcrawford@...tem76.com,
tiwai@...e.com, xuwd1@...mail.com, yangyingliang@...wei.com,
yangyuchi66@...il.com
Subject: Re: [PATCH 0/2] Fix CSC3551 speaker sound problem for machines without a valid ACPI _DSD
Hi Takashi,
On Sun, 16 Jul 2023 14:49:18 +0200 you wrote:
> 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.
Agreed.
> 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.
I do have noticed that the existing entries in patch_realtek.c are enough
for locating the right quirk. However I'm unsure if these entries can
be moved to that file since the cs35l41 i2c/spi devices are instantiated
by the serial-multi-instantiate driver, and if no proper _DSD is found
the cs35l41 driver would just fail with no corresponding i2c/spi devices.
I don't know if it is possible for the hda driver to intervene this
probing process.
> - The workaround is a workaround, and it's fundamentally dangerous.
> We should warn it in a kernel message.
Agreed. I will update my patches to emit a warning message, however as
Stuart has replied, a patch series which is cleaner is on its way in few
weeks and I would not submit a new version for now. I am looking forward
to Cirrus's work.
Regards,
David.
Powered by blists - more mailing lists