linux-kernel - Re: [PATCH] ALSA: hda: cs35l41: Support ASUS 2023 laptops with missing DSD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1883002.tdWV9SEqCh@nobara-desktop-pc>
Date:   Thu, 24 Aug 2023 21:48:27 -0700
From:   Jonathan LoBue <jlobue10@...il.com>
To:     Stefan Binding <sbinding@...nsource.cirrus.com>,
        Luke Jones <luke@...nes.dev>
Cc:     'Takashi Iwai' <tiwai@...e.de>, tiwai@...e.com,
        james.schulman@...rus.com, david.rhodes@...rus.com,
        rf@...nsource.cirrus.com, linux-kernel@...r.kernel.org,
        patches@...nsource.cirrus.com
Subject: Re: [PATCH] ALSA: hda: cs35l41: Support ASUS 2023 laptops with missing DSD

On Wednesday, August 23, 2023 1:31:06 PM PDT Luke Jones wrote:
> > The second member variable in cs35l41_prop_model_table is the SSID to
> > match against.
> > The Lenovo laptops in the initial patch didn't have different SSIDs so
> > the entry was set to NULL for those.
> > Future entries using CSC3551 MUST always have an accompanying SSID
> > with this entry.
> > Takashi was correct, the implementation is intended to also be used to
> > patch incorrect DSD.
> > 
> > We have a potential solution to workaround the SPI cs-gpios issue
> > inside here,
> > though the drawback for that is that it only works for laptops with 2
> > SPI amps.
> 
> Can you provide me this so I can test? I have laptops with SPI 2 and 4
> speaker setups.
> 
> > I also took a look at the function for applying DSD properties for the
> > 2023 ROG laptops.
> > Unfortunately the one-size-fits-all approach will not work, some of
> > these laptops are i2c
> > and some are SPI, meaning the GPIO indexes are different for different
> > laptops.
> 
> Do you mean "spk-id-gpios"? For all the laptops I know of this seems to
> be
> Package () { "spk-id-gpios", Package () {
>     SPK1, 0x02, Zero, Zero,
>     SPK1, 0x02, Zero, Zero
> } },
> 
> There is one laptop where it is One not 0x02 (the GA402N)
> 
> > Some of the laptops do no have Speaker IDs.
> > Also, no laptop other than the 2 I added already should ever use
> > CS35L41_EXT_BOOST_NO_VSPK_SWITCH (in fact I believe all these laptops
> > are internal
> > boost anyway).
> 
> Grazie.
> 
> > We are currently working internally on adding support for the 2023 ROG
> > laptops, so we
> > ask for you guys to hold off on trying to upstream support for these
> > laptops.
> 
> Ah great. Thank you. I apologise for trying to rush things, but I do
> have a discord server of over 4000 people, many of whom have laptops
> with cirrus amps.
> 
> For now I'm including a patch in my kernel builds with this mapping:
> 
> const struct cs35l41_prop_model cs35l41_prop_model_table[] = {
> 	{ "CLSA0100", NULL, lenovo_legion_no_acpi },
> 	{ "CLSA0101", NULL, lenovo_legion_no_acpi },
> 	{ "CSC3551", "10431433", asus_rog_2023_no_acpi }, // ASUS GS650P - 
i2c
> 	{ "CSC3551", "10431463", asus_rog_2023_no_acpi }, // ASUS GA402X - 
i2c
> 	{ "CSC3551", "10431473", asus_rog_2023_no_acpi }, // ASUS GU604V - 
spi
> 	{ "CSC3551", "10431483", asus_rog_2023_no_acpi }, // ASUS GU603V - 
spi
> 	{ "CSC3551", "10431493", asus_rog_2023_no_acpi }, // ASUS GV601V - 
spi
> 	{ "CSC3551", "10431573", asus_rog_2023_no_acpi }, // ASUS GZ301V - 
spi
> 	{ "CSC3551", "104317F3", asus_rog_2023_no_acpi }, // ASUS ROG ALLY 
-
> i2c
> 	{ "CSC3551", "10431B93", asus_rog_2023_no_acpi }, // ASUS G614J - 
spi
> 	{ "CSC3551", "10431CAF", asus_rog_2023_no_acpi }, // ASUS G634J - 
spi
> 	{ "CSC3551", "10431C9F", asus_rog_2023_no_acpi }, // ASUS G614JI -
spi
> 	{ "CSC3551", "10431D1F", asus_rog_2023_no_acpi }, // ASUS G713P - 
i2c
> 	{ "CSC3551", "10431F1F", asus_rog_2023_no_acpi }, // ASUS H7604JV - 
spi
> 	{}
> };
> 
> These are the machines I have verified the gpios and such for.
> 
> Cheers,
> Luke.

Stefan,

Based on your comment, "in fact I believe all these laptops are internal boost 
anyway," that would imply that we want to update our temporary patches that we 
are using for kernel creation (and sharing via RPM or other means). Right now 
we had updated that line to hw_cfg->bst_type = CS35L41_EXT_BOOST; but it seems 
that it should actually be hw_cfg->bst_type = CS35L41_INT_BOOST. The external 
boost setting seems to work for the ASUS ROG ALLY in my own testing, but 
perhaps it is driving the amp harder than intended. Based on available 
documentation, the internal boost setting must be accompanied by the peak 
current, inductor and capacitor values of the boost circuit. It's possible 
that ASUS used some different values here for board components across different 
laptop models (and the ALLY). If you have the table with accurate values for 
the capacitance and inductance values (and for which models they apply), that 
would be very valuable information to share. As Luke pointed out, many people 
are wanting to use these patches now to avoid the need for DSD ACPI overrides 
to get audio working on their devices.

I'm most interested in the capacitance and inductance values for the ROG ALLY, 
so that I can fill in the values for hw_cfg->bst_ind and hw_cfg->bst_cap. Peak 
current seems to be okay to leave at 4,500mA as I can't imagine that Cirrus 
would allow an unsafe current value there, and in documentation it's listed as 
default anyways. We will wait for your upstream patch, but we would also very 
much appreciate if you could share this information if you have it and are 
able to share it. Thanks.

Best Regards,
Jon LoBue