To me it looks that this DSDT doesn't have the needed properties, so ASUS would need to add those in a BIOS update.  Please contact them to get the firmware fixed.

https://github.com/torvalds/linux/blob/d7227785e384d4422b3ca189aa5bf19f462337cc/sound/pci/hda/cs35l41_hda.c#L319

On Windows, it functions perfectly. I believe we should wait to hear from Cirrus devs.

Other platforms with this amplifier must have this information added to BIOS specifically for Linux as it's otherwise not discoverable information.

Let me attach a dsdt from a platform that did it right to demonstrate.  These values aren't necessarily correct for your system, ASUS needs to put the right ones in for your system.

Created attachment 301471 [details]
snippet from DSDT on another platform that works properly

I understood it. Why this is not necessary for the Windows driver baffles me.

I don't know the details either but if I was going to guess you could specify this type of info in the INF for Windows.  Maybe poke around the Windows driver for similar info for your system.  If it is indeed in the INF maybe a quirk for this system to set device properties is doable from that information.

The "proper" solution is to have it in the BIOS though.

Unfortunately, ASUS said they don't provide tech support for Linux.

Created attachment 301529 [details]
INF file for Windows drivers for codec 9333.1

Created attachment 301530 [details]
INF file for Windows drivers for driver 9333.1

I have attached a two of the INF files shipped with Windows. The codec one has many stuff in it that seems to relate to something that could be in DSDT. Does it look familiar?

The driver ships all these INF files:

Codec_9333.1/HDXACPASUS.inf
ExtRtk_9333.1/HDX_AsusExt_DOLBY_DSP_Wrap_RTKGen4.inf
ExtRtk_AmdDMIC_146/AmdDMicExt_Asus.inf
ExtRtk_AmdDMIC_146/AmdDMicExtT_Asus_104315DF.inf
ExtRtk_APO_Tuning_9333/HDX_AsusExt_APOT_2-63_off_basic.inf
ExtRtk_APO_Tuning_9333/HDX_AsusExt_APOT_AD72_C.inf
ExtRtk_APO_Tuning_9333/HDX_AsusExt_SpDllT_2-63.inf
OVWrap2_25/OVWrap2.inf
RealtekAPO2_1040/RealtekAPO2.inf
RealtekASIO_8/RealtekASIO.inf
RealtekHSA_270/RealtekHSA.inf
RealtekINTAPO2_1040/RealtekINTAPO2.inf
RealtekService_511/RealtekService.inf

I suppose the AmdDMIC ones could help with the mic not working as well.

> Does it look familiar?

It doesn't directly match anything like the DSDT information I referenced above (no mention of word GPIO or index).

Maybe you should start with the snippet I shared and try to set up a quirk for your system using that information as a reference from a working system.  It all depends on whether the design is different for this OEM or not from the one I shared the snippet from.
 
> I suppose the AmdDMIC ones could help with the mic not working as well.

If the DMIC isn't working, I would start out with adding the platform to https://github.com/torvalds/linux/blob/master/sound/soc/amd/yc/acp6x-mach.c#L47

and make sure that you have the right driver matching it selected in your kernel config.

Created attachment 301584 [details]
csaudio.inf from UM5302TA

Created attachment 301585 [details]
csaudioext.inf from UM5302TA

Those INFs appear to have no meaningful information. Is there anything I missed?

I think it's worth raising this discussion on the mailing list for your case.

I'm not familiar with the LKML. Which mailing list should I use? linux-audio or alsa-devel?

BTW it appears that another laptop model has a similar issue.
https://lore.kernel.org/all/20220811053950.11810-1-faenkhauser@gmail.com/T/

From my perspective this is still a BIOS bug.  The OEM /should/ be populating the relevant _DSD.

But for this discussion on a quirk and what it should be, I suggest alsa-devel ML.  I'm pretty sure you'll at least be able to get Cirrus guys attention.

Created attachment 301611 [details]
dmesg from Lenovo Legion 7i Gen7

Created attachment 301612 [details]
ACPI dump from Lenovo Legion 7i Gen7

The Lenovo Legion 7i Gen 7 also has non-working sound with the CSC3551.

I don't have a Lenovo Legion 7i Gen 7 myself, but I've been working with someone who does. I just attached the ACPI dump and dmesg they shared from their system.

The Intel HDA early patching method was used to apply the CSC3551 i2c quirk.

Here is their alsa-info as well:
http://alsa-project.org/db/?f=0be0a7575b5bcc9534f5e301194db6f31f614eba

Here's the relevant section from the dump:
    Scope (_SB.PC00.I2C2)
    {
        Name (I2CN, Zero)
        Name (I2CX, Zero)
        Name (I2CI, 0x02)
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            I2CN = SDS2 /* \SDS2 */
            I2CX = 0x02
        }

        Device (SPK1)
        {
            Name (_HID, "CSC3551")  // _HID: Hardware ID
            Name (_UID, One)  // _UID: Unique ID
            Name (_SUB, "17AA3874")  // _SUB: Subsystem ID
            Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                If ((SPID == Zero))
                {
                    _SUB = "17AA3874"
                    Return (Zero)
                }

                If ((SPID == One))
                {
                    _SUB = "17AA386F"
                    Return (Zero)
                }
            }

            Name (GPIB, ResourceTemplate ()
            {
                GpioIo (Exclusive, PullDown, 0x0000, 0x0000, IoRestrictionOutputOnly,
                    "\\_SB.GPI0", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0027
                    }
                GpioIo (Shared, PullUp, 0x0064, 0x0000, IoRestrictionInputOnly,
                    "\\_SB.GPI0", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0026
                    }
                GpioInt (Edge, ActiveBoth, Shared, PullUp, 0x0064,
                    "\\_SB.GPI0", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0026
                    }
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (IBUF, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x0040, ControllerInitiated, 0x000F4240,
                        AddressingMode7Bit, "\\_SB.PC00.I2C2",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                    I2cSerialBusV2 (0x0041, ControllerInitiated, 0x000F4240,
                        AddressingMode7Bit, "\\_SB.PC00.I2C2",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                })
                Return (ConcatenateResTemplate (IBUF, GPIB))
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }

            Method (_DIS, 0, NotSerialized)  // _DIS: Disable Device
            {
            }
        }
    }

I wonder if updating the DSDT to include the missing properties would the way to go for the initial testing:
https://wiki.archlinux.org/title/DSDT#Find_a_fixed_DSDT

All assuming that the example of working properties would even be valid.

Perhaps the values needed are hardcoded into the drivers (or the tunings)...

Another possibility, is that the drivers assume default values if the relevant values are not in the DSDT.

FYI - this patch just went up.

https://patchwork.kernel.org/project/alsa-devel/patch/20220815162906.463108-1-sbinding@opensource.cirrus.com/

Created attachment 301660 [details]
Initial but dangerous support for Lenovo Legion 7i Gen7. Use at your own risk.

I went ahead and tried hard coding some values. This is against kernel 5.19.4 and sound does partially work.

It's all rather hacky, but you can make changes under the 'csc3551:' label in 'sound/pci/hda/cs35l41_hda.c'

But I do get left channel audio out of the right speaker. However, as a warning, I suspect this is fine, but I can't guarantee it. I get this potentially ominous message in dmesg:
[  412.976460] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Amp short error

I think this is probably really easy to fix (just need to adjust some of the more obvious values I'd guess), but I don't have a lot of time today so I'm sharing it in case someone else wants to play with it.

If you don't have the same model of laptop as me, don't forget to add a quirk for your laptop under 'sound/pci/hda/patch_realtek.c'

Created attachment 301669 [details]
lenovo-7i-gen7-0.0.1.patch

This patch gives me full working sound on the Lenovo Legion 7i Gen 7 (16IAX7). It's for 5.19.4. I suspect it's fairly safe, but use at your own risk.

As it is, it won't be accepted into the kernel (and nor should it be). But it shows you can get sound working without the values in the DSDT.

I wonder if Cirrus Logic has plans to support quirks for different laptops, etc in their driver?

One big caveat, is that when resuming from sleep/hibernate, you will no longer have sound. Does anyone know if this is true in general for CSC3551 based systems? I know it's true for the CLSA0101 (which is supported by the same driver) and that a patch to fix that is coming eventually according to Cirrus Logic.

XiaoYan Li, this might work for you. You'll just need to add a quirk line for your specific model of laptop.

> This patch gives me full working sound on the Lenovo Legion 7i Gen 7
> (16IAX7). It's for 5.19.4. I suspect it's fairly safe, but use at your own
> risk.

Good job!

> As it is, it won't be accepted into the kernel (and nor should it be). But it
> shows you can get sound working without the values in the DSDT.

Yeah not the way it's built up right now it wouldn't be.

> I wonder if Cirrus Logic has plans to support quirks for different laptops,
> etc in their driver?

You can certainly do a cleaner quirk from your existing patch that can potentially be mainlined and discuss it.  You'll want to add a DMI match table and just run that new code when your system is detected.

I reached out to the submitter of this patch to see if there is already some work to enable device specific works or at least plans for it:
https://www.spinics.net/lists/alsa-devel/msg146157.html

(In reply to Mario Limonciello (AMD) from comment #25)

> You can certainly do a cleaner quirk from your existing patch that can
> potentially be mainlined and discuss it.  You'll want to add a DMI match
> table and just run that new code when your system is detected.

Looking at the DMI match stuff, it seems fairly straight forward.

If there are not even plans to enable quirks for machines that lack the otherwise necessary _DSD properties, it's something I'd be willing work on.

Created attachment 301704 [details]
lenovo-7i-gen7-0.0.2.patch

No change in functionality, but cleaned up the original patch a bit.

I'm also setting the GPIO reset pin correctly (or at least less incorrectly) for each amp chip resulting in no longer seeing this message: "Reset line busy, assuming shared reset"

At least another model was reported to have the same missing nodes (bug 216446).  So if your quirk methodology ends up working it would be good to get data for both models in place.

Unfortunately, Cirrus Logic got back to me and stated that what I'm doing isn't a great idea as utilizing the wrong settings could potentially physically damage your speakers.

I hadn't updated on this sooner to see if they'd follow up with me, but so far they have not.

If you have an unsupported model, your best bet is to ask the laptop vendor to update their BIOS with this information. Perhaps if a vendor gets enough requests, they may actually even do it.

I'm still holding off before I ask Lenovo, but if I don't hear back from Cirrus logic within the next 1-2 weeks, I'm going to give it a shot. In my experience, Lenovo has been pretty uncooperative with this sort of thing when it comes to models that aren't explicitly Linux supported so I won't be holding my breath.

Thanks.

I think that's enough of a reason that we should close this issue.  Anyone affected by this should report the issue to the OEM to get fixed in BIOS.

I opened a ticket with Asus for the UM3402Y and they've replied with "Our team has advised that we will forward this information to our senior team for review for future design consideration once we start supporting Linux OS."

Time to sit back and wait, but at least it's hopeful.

Created attachment 303151 [details]
lenovo-7i-gen7-sound-6.1.0-rc4-0.0.2.patch

Updated patch that works with 6.1-rc4. 6.1 has support for suspend/resume so in conjunction with this patch, you get full proper sound support. Still no issues with the speakers so probably in good shape.

Created attachment 303506 [details]
lenovo-7i-gen7-sound-6.2.0-rc1-0.0.3.patch

Currently, Nvidia drivers don't work with 6.2*, but 6.2* does allow you to increase your refresh rate to 165 Hz instead of being stuck at merely 60.

So this patch could be useful if you have no gaming or CUDA work worked planned in the near future. Plus, I'm getting ahead of 6.2* support.

NOTE: This is still use at your own risk. However, I have it on good word that after several months of Linux usage nearly absolutely everyday, there are no issues.

(In reply to Cameron Berkenpas from comment #33)
> Created attachment 303506 [details]
> lenovo-7i-gen7-sound-6.2.0-rc1-0.0.3.patch
> 
> Currently, Nvidia drivers don't work with 6.2*, but 6.2* does allow you to
> increase your refresh rate to 165 Hz instead of being stuck at merely 60.
> 
> So this patch could be useful if you have no gaming or CUDA work worked
> planned in the near future. Plus, I'm getting ahead of 6.2* support.

As a "cleaner" patch perhaps you can do it as an DSDT/SSDT patch that is loaded by your bootloader (IE GRUB) or contained within the initrd.

It would also illustrate exactly what the OEM needs to put into their BIOS for them to fix it properly.

Unfortunately, I don't have exactly what's needed for this model of laptop. The values are guessed and there are several optional values that can be set (but of course, aren't). MIGHT be useful as an example?

I've already tried the approach with doing the DSDT approach and even had some success this way with the guessed values... But one speaker would keep going out with an "Amp Short" error in dmesg.

My patch behaves somewhat differently than what we get with the DSDT entries since it's based on an older version of the cs35l41 driver and so doesn't have that particular issue for whatever reason.

I suppose I could narrow it down to which part is results in this issue, but haven't had the time.

My current patch is the best that can be done for the Lenovo Legion 7i Gen 7, at least for now.

(In reply to Mario Limonciello (AMD) from comment #35)
> As a "cleaner" patch perhaps you can do it as an DSDT/SSDT patch that is
> loaded by your bootloader (IE GRUB) or contained within the initrd.
> 
> It would also illustrate exactly what the OEM needs to put into their BIOS
> for them to fix it properly.

Does this patch also work for the Legion Slim 7i Gen 7 (16IAH7)?

It could be adapted to work for it by adding a quirk.

That being said, the slim version likely needs different settings. Using 
wrong settings could damage the laptop.

How do I know this patch is fairly safe on the non-Slim Gen 7 Legion 79? 
Because it's been used  daily for months without issue.

On 1/6/2023 1:22 PM, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> jmaximusix@gmail.com changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |jmaximusix@gmail.com
>
> --- Comment #37 from jmaximusix@gmail.com ---
> Does this patch also work for the Legion Slim 7i Gen 7 (16IAH7)?
>

Thanks for your answer, however I have no clue on how to do that. Also, I don’t quite understand the meaning of these so calles “_DSD properties”, what exactly are they and in what way can wrong settings damage my hardware?
It would be super cool if you could tell me what information you need me to provide to make this work for my laptop model or if not, could you maybe point me in a direction on where to look to be able to adapt this to work for my laptop myself, but I’m not an expert, so I don‘t know if I’m able to.
Thanks in advance!


(In reply to Cameron Berkenpas from comment #38)
> It could be adapted to work for it by adding a quirk.
> 
> That being said, the slim version likely needs different settings. Using 
> wrong settings could damage the laptop.
> 
> How do I know this patch is fairly safe on the non-Slim Gen 7 Legion 79? 
> Because it's been used  daily for months without issue.
> 
> On 1/6/2023 1:22 PM, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=216194
> >
> > jmaximusix@gmail.com changed:
> >
> >             What    |Removed                     |Added
> >
> ----------------------------------------------------------------------------
> >                   CC|                            |jmaximusix@gmail.com
> >
> > --- Comment #37 from jmaximusix@gmail.com ---
> > Does this patch also work for the Legion Slim 7i Gen 7 (16IAH7)?
> >

_DSD properties are "Device Specific Data" for an ACPI device.  They are used to express how and what hardware is connected.  If you use the wrong values you might (for example) blow your speakers.

Created attachment 303570 [details]
lenovo-7i-gen7-sound-6.2.0-rc3-0.0.3.patch

The previous patch included a fix that is now already in rc3, preventing the old 6.2.0-rc1 patch from not applying cleaning to rc3. This fixes that.

So it'll work with the Legion Slim 7i Gen 7? Sorry if I'm asking dumb questions, just want to be sure, if so, thats absolutely amazing, thank you!

(In reply to Cameron Berkenpas from comment #41)
> Created attachment 303570 [details]
> lenovo-7i-gen7-sound-6.2.0-rc3-0.0.3.patch
> 
> The previous patch included a fix that is now already in rc3, preventing the
> old 6.2.0-rc1 patch from not applying cleaning to rc3. This fixes that.

Sorry, my bad, must have misunderstood, you just updated the fix for your laptop to the latest kernel, right?

(In reply to jmaximusix from comment #43)
> Sorry, my bad, must have misunderstood, you just updated the fix for your
> laptop to the latest kernel, right?

Correct. If you want me to add a quirk for your laptop, I need your alsa-info.

Here it is, if you need anything else let me know, thank you so much!
http://alsa-project.org/db/?f=b6e28d60ea6010ece2066e33c1bf1aa72f9f8d25

Created attachment 303571 [details]
lenovo-7i-gen7-sound-6.2.0-rc3-0.0.4.patch

Adds experimental Legion S7 16IAH7 (Gen 7 slim) support.

Other minor improvements.

At the very minimum, your kernel should have the following configured:
CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_I2C=m

Hi! Thank you so much for trying to help me out. Unfortunately, however, I wasn't able to make it work. Because I'm not an expert by any means tho, I'm not sure whether this could just be my fault.
Here's what I tried so far:

- downloaded kernel version 6.2.0-rc3 from kernel.org
- used the endeavourOS default .config and made sure the config options you mentioned are set (they already were)
- applied your patch and compiled the kernel
=> unfortunately still no working audio

I tried the same thing with a small modification to your patch, changing the "Legion 7 16IAH7" in line 128 to "Legion S7 16IAH7" since I wasn't quite sure if this was a typo (?), but still no success after recompiling the kernel

Am I missing something?
I'm also not sure if I just got some configs (alsa/whatever) wrong, I tried a bunch of things with no success yet. 

I also noticed that the output of `dmesg | grep error`
still lists:
[    0.009609] [Firmware Bug]: TSC ADJUST differs within socket(s), fixing all errors
[    5.349307] Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENOENT: Error requesting irq at index 0
[    5.351682] Serial bus multi instantiate pseudo device driver: probe of CSC3551:00 failed with error -2
[    5.964098] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2

and I'm not sure if the second and third line here imply that the fix in fact didn't work?

I'd really appreciate any help. If I can provide any other debugging information, just ask for it, I just don't know what to include here because I don't really know what's helpful
Thanks in advance!

(In reply to Cameron Berkenpas from comment #46)
> Created attachment 303571 [details]
> lenovo-7i-gen7-sound-6.2.0-rc3-0.0.4.patch
> 
> Adds experimental Legion S7 16IAH7 (Gen 7 slim) support.
> 
> Other minor improvements.
> 
> At the very minimum, your kernel should have the following configured:
> CONFIG_SND_HDA_SCODEC_CS35L41=m
> CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
> CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
> CONFIG_SND_SOC_CS35L41_LIB=m
> CONFIG_SND_SOC_CS35L41=m
> CONFIG_SND_SOC_CS35L41_SPI=m
> CONFIG_SND_SOC_CS35L41_I2C=m

My last follow up was blocked by SpamAssassin. So now I'm posting again through the site:

Are you sure you're running the right kernel? Try:
uname -a

Attach the entire contents of your dmesg to this bug.

Created attachment 303584 [details]
dmesg output on my Legion Slim 7i with patch applied

uname -r
-> 6.2.0-rc3-mylegionfix

So I definitely am running my custom kernel, however I don't really know how to 100% verify the patch has beed applied correctly (99.9% certain tho, at least I checked the files if they had been correctly changed before compiling it)

I attached the entire dmesg output, hope hat helps, and thanks so much for your time and patience.

(In reply to jmaximusix from comment #49)
> Created attachment 303584 [details]
> dmesg output on my Legion Slim 7i with patch applied
> 
> uname -r
> -> 6.2.0-rc3-mylegionfix
> 
> So I definitely am running my custom kernel, however I don't really know how
> to 100% verify the patch has beed applied correctly (99.9% certain tho, at
> least I checked the files if they had been correctly changed before
> compiling it)
> 
> I attached the entire dmesg output, hope hat helps, and thanks so much for
> your time and patience.

It seems it there's a problem getting the hardware going. This is a separate issue that occurs before any of the coded added by my hacky patch can even be run. Unfortunately, I don't know what it's happening.

Do you get the same kind of error with the stock kernel (assuming the stock kernel is recent enough for CSC3551 support)?

What version is your stock vendor kernel BTW?

I see from your alsa-info, that the stock vendor kernel is 6.1.4-arch1-1

That's definitely recent enough. What messages relating to CSC3551 do you get in dmesg there? If it's able to pick up the hardware... maybe there's a bug in 6.2 that affects you hardware.

The dmesg on the stock kernel contains the same 2 errors regarding "CSC3551".
I came across this bug where people seem to relate it back to cs35l41, I've got no clue about this stuff, but maybe you can make sense of it...

https://bugzilla.kernel.org/show_bug.cgi?id=215993

One comment also links to this:

https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus/cs35l41

although I'm not quite certain if that means it's already in the linux kernel by now or not.

I might be completely on the wrong track here as I don't understand much of any of this, I'll try and look further into it tomorrow as much as I can but I doubt I'll find solutions completely on my own.

I don't take your further help for granted and really appreciate what you've already done for me, however I'd be very grateful if you could maybe take a look at it.
Thank you in advance!

(In reply to jmaximusix from comment #52)
> The dmesg on the stock kernel contains the same 2 errors regarding "CSC3551".
> I came across this bug where people seem to relate it back to cs35l41, I've
> got no clue about this stuff, but maybe you can make sense of it...
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=215993
I saw that earlier too... May or may not be related.


> 
> One comment also links to this:
> 
> https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus/cs35l41
> 
> although I'm not quite certain if that means it's already in the linux
> kernel by now or not.
Sadly, this is probably just for Lenovo's Linux supported laptops. Though it means that they do have some know-how on how to add the relevant DSD intros into the BIOS.

I'm not really sure what's going on here either... Maybe there's a way you can report this issue to Cirrus Logic? Most likely, your laptop is missing the DSD entries, so once this is fixed, you'd still need a workaround like my patch.

Cirrus Logic might be interested in fixing another corner case.

On a tangential note... The latest BIOS version for my laptop is from July. I think I've had it since September? Weird that Lenovo hasn't had any updates for it, but maybe we'll get lucky?

Make sure you have the latest BIOS. Even if updating doesn't add DSD entries (probably not), there is a _slight_ chance it could fix your current issue.

(In reply to Cameron Berkenpas from comment #46)
> Created attachment 303571 [details]
> lenovo-7i-gen7-sound-6.2.0-rc3-0.0.4.patch
> 
> Adds experimental Legion S7 16IAH7 (Gen 7 slim) support.
> 
> Other minor improvements.
> 
> At the very minimum, your kernel should have the following configured:
> CONFIG_SND_HDA_SCODEC_CS35L41=m
> CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
> CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
> CONFIG_SND_SOC_CS35L41_LIB=m
> CONFIG_SND_SOC_CS35L41=m
> CONFIG_SND_SOC_CS35L41_SPI=m
> CONFIG_SND_SOC_CS35L41_I2C=m

I'm happy to report that this patch works for the Lenovo ThinkBook Plus Gen 3 as well (17aa:3891)

That's great news. Thank you for reporting this!

Created attachment 303814 [details]
lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b.patch

Added experimental 16ARHA7 support.

This is a very much use at your own risk scenario. These are guessed values that have worked for the Legion 7i Gen 7 for an extended period of time without issue. 

Sounds like the Intel based 7i has been working (can anyone followup?) so this could be okay too. If you encounter issues which may include but is not limited to distorted sound, loudness, and perhaps "amp short" errors in dmesg, stop using this patch for your slim.

(In reply to Cameron Berkenpas from comment #46)
> Created attachment 303571 [details]
> lenovo-7i-gen7-sound-6.2.0-rc3-0.0.4.patch
> 
> Adds experimental Legion S7 16IAH7 (Gen 7 slim) support.

Hi Cameron, I have a Legion 7 16IAX7, so I tried to apply your patch, but I still have no sound. I am running kernel 6.2.1, so I applied the patch manually since the line numbers didn't match. The kernel works just fine, with the following dmesg outputs:

(stock kernel)
$ uname -sr
Linux 6.2.1-arch1-1
$ sudo dmesg | grep CSC3551
[    3.453341] Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 I2C devices.
[    3.550639] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD Properties are missing for HID CSC3551.
[    3.551697] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported
[    3.552809] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with error -22
[    3.553217] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD Properties are missing for HID CSC3551.
[    3.554134] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error -EINVAL: Platform not supported
[    3.555026] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with error -22

(with patch)
$ uname -sr
Linux 6.2.1-arch1-1-legion7
$ sudo dmesg | grep CSC3551
[    3.224156] Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 I2C devices.
[    3.382932] CSC3551: probing CSC3551
[    3.382976] CSC3551: no_acpi_dsd: CSC3551
[    3.382978] CSC3551: id == 0x40
[    3.383156] CSC3551: Done.
[    3.437900] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[    3.437945] CSC3551: probing CSC3551
[    3.437963] CSC3551: no_acpi_dsd: CSC3551
[    3.437963] CSC3551: id == 0x41
[    3.438058] CSC3551: Done.
[    3.475528] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2

However as I said there is still no sound (even on the fallback initramfs, fwiw). What do you think could be the reason? Thank you for all your work on this issue.

Are you sure none of your sound is muted? This is something I've seen 
many times over the years.

Try alsa-mixer maybe?

Try the sound settings for your laptop. Maybe something (like the output 
device) is misconfigured?

The output from the patched kernel strongly suggests it's working 
(though there's likely more related dmesg output than what you've shared 
which could be helpful).

In case it wasn't clear, I have the exact same model of laptop as you so 
it should definitely work.

On 3/1/23 07:47, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> Jacopo G. Chen (jacopo.chen256@gmail.com) changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |jacopo.chen256@gmail.com
>
> --- Comment #57 from Jacopo G. Chen (jacopo.chen256@gmail.com) ---
> (In reply to Cameron Berkenpas from comment #46)
>> Created attachment 303571 [details]
>> lenovo-7i-gen7-sound-6.2.0-rc3-0.0.4.patch
>>
>> Adds experimental Legion S7 16IAH7 (Gen 7 slim) support.
> Hi Cameron, I have a Legion 7 16IAX7, so I tried to apply your patch, but I
> still have no sound. I am running kernel 6.2.1, so I applied the patch
> manually
> since the line numbers didn't match. The kernel works just fine, with the
> following dmesg outputs:
>
> (stock kernel)
> $ uname -sr
> Linux 6.2.1-arch1-1
> $ sudo dmesg | grep CSC3551
> [    3.453341] Serial bus multi instantiate pseudo device driver CSC3551:00:
> Instantiated 2 I2C devices.
> [    3.550639] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD
> Properties are missing for HID CSC3551.
> [    3.551697] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error -EINVAL:
> Platform not supported
> [    3.552809] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with
> error -22
> [    3.553217] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD
> Properties are missing for HID CSC3551.
> [    3.554134] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error -EINVAL:
> Platform not supported
> [    3.555026] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with
> error -22
>
> (with patch)
> $ uname -sr
> Linux 6.2.1-arch1-1-legion7
> $ sudo dmesg | grep CSC3551
> [    3.224156] Serial bus multi instantiate pseudo device driver CSC3551:00:
> Instantiated 2 I2C devices.
> [    3.382932] CSC3551: probing CSC3551
> [    3.382976] CSC3551: no_acpi_dsd: CSC3551
> [    3.382978] CSC3551: id == 0x40
> [    3.383156] CSC3551: Done.
> [    3.437900] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41
> (35a40), Revision: B2
> [    3.437945] CSC3551: probing CSC3551
> [    3.437963] CSC3551: no_acpi_dsd: CSC3551
> [    3.437963] CSC3551: id == 0x41
> [    3.438058] CSC3551: Done.
> [    3.475528] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41
> (35a40), Revision: B2
>
> However as I said there is still no sound (even on the fallback initramfs,
> fwiw). What do you think could be the reason? Thank you for all your work on
> this issue.
>

Created attachment 303823 [details]
dmesg on patched Legion 7 16IAX7

Thank you for your quick reply. Here is the output from dmesg on the patched kernel (uname -sr --> Linux 6.2.1-arch1-1-legion7). I tried speaker-test and the tests from KDE's audio settings, with both intel and nvidia cards, to no avail. Alsamixer shows nothing muted except for S/PDIF (unmuting it changes nothing). When I try to play some sound, the system tray GUI volume indicator moves (showing changes in output volume),
I use wireplumber, but this should be immaterial: in my understanding speaker-test is more low-level as it interfaces directly with ALSA.

Created attachment 303824 [details]
attachment-26853-0.html

What BIOS version are you running? I'm running the latest from here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/legion-series/legion-7-16iax7/downloads/driver-list/component?name=BIOS%2FUEFI

Which is version K1CN40WW

I doubt that's the reason, but worth a shot if you haven't tried it.

Can you provide a link to your alsa-info? I don't think you've provided 
that yet.

Here's what my output looks like:
[   15.163991] Serial bus multi instantiate pseudo device driver 
CSC3551:00: Instantiated 2 I2C devices.
[   15.177667] CSC3551: probing CSC3551
[   15.177687] CSC3551: no_acpi_dsd: CSC3551
[   15.177688] CSC3551: id == 0x40
[   15.177689] Serial bus multi instantiate pseudo device driver 
CSC3551:00: using ACPI '\_SB.PC00.I2C2.SPK1' for '(null)' GPIO lookup
[   15.177694] acpi CSC3551:00: GPIO: looking up gpios
[   15.177696] acpi CSC3551:00: GPIO: looking up gpio
[   15.177697] acpi CSC3551:00: GPIO: looking up 0 in _CRS
[   15.177835] CS3551: reset_gpio == 0xc5058618
[   15.177837] CSC3551: Done.
[   15.207653] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC287: 
line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
[   15.207655] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   15.214974] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic 
CS35L41 (35a40), Revision: B2
[   15.215017] CSC3551: probing CSC3551
[   15.215431] CSC3551: no_acpi_dsd: CSC3551
[   15.215432] CSC3551: id == 0x41
[   15.215434] Serial bus multi instantiate pseudo device driver 
CSC3551:00: using ACPI '\_SB.PC00.I2C2.SPK1' for '(null)' GPIO lookup
[   15.215438] acpi CSC3551:00: GPIO: looking up gpios
[   15.215440] acpi CSC3551:00: GPIO: looking up gpio
[   15.215441] acpi CSC3551:00: GPIO: looking up 1 in _CRS
[   15.215998] acpi CSC3551:00: Override GPIO initialization flags
[   15.216136] CS3551: reset_gpio == 0xc50585f0
[   15.216139] CSC3551: Done.
[   15.253685] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware 
version: 3
[   15.253687] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: 
cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Jun 2022 14:55:56 GMT Daylight 
Time
[   15.716983] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware: 
400a4 vendor: 0x2 v0.58.0, 2 algorithms
[   15.718190] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: 0: ID cd 
v29.78.0 XM@94 YM@e
[   15.718208] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: 1: ID 
f20b v0.1.0 XM@17c YM@0
[   15.718219] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: spk-prot: 
e:\workspace\workspace\tibranch_release_playback_6.76_2\ormis\staging\default_tunings\internal\CS35L53\Fixed_Attenuation_Mono_48000_29.78.0\full\Fixed_Attenuation_Mono_48000_29.78.0_full.bin
[   15.734385] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cannot Write 
Control: CAL_AMBIENT - 1
[   15.734390] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cannot 
Initialize Firmware. Error: 1
[   15.735295] snd_hda_codec_realtek hdaudioC0D0: bound 
i2c-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_playback_hook.cold 
[snd_hda_scodec_cs35l41])
[   15.735327] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware 
version: 3
[   15.735328] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: 
cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Jun 2022 14:55:56 GMT Daylight 
Time
[   16.198676] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware: 
400a4 vendor: 0x2 v0.58.0, 2 algorithms
[   16.199910] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: 0: ID cd 
v29.78.0 XM@94 YM@e
[   16.199928] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: 1: ID 
f20b v0.1.0 XM@17c YM@0
[   16.199935] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: spk-prot: 
e:\workspace\workspace\tibranch_release_playback_6.76_2\ormis\staging\default_tunings\internal\CS35L53\Fixed_Attenuation_Mono_48000_29.78.0\full\Fixed_Attenuation_Mono_48000_29.78.0_full.bin
[   16.216078] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cannot Write 
Control: CAL_AMBIENT - 1
[   16.216083] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cannot 
Initialize Firmware. Error: 1


The only thing that stands out is the reset_gp io address... but I think 
that's probably not the cause. Both our addresses are in the upper 3GB 
for kernel space and nothing indicates an error so it's probably nothing.

On 3/1/23 08:54, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #59 from Jacopo G. Chen (jacopo.chen256@gmail.com) ---
> Created attachment 303823 [details]
>    -->https://bugzilla.kernel.org/attachment.cgi?id=303823&action=edit
> dmesg on patched Legion 7 16IAX7
>
> Thank you for your quick reply. Here is the output from dmesg on the patched
> kernel (uname -sr --> Linux 6.2.1-arch1-1-legion7). I tried speaker-test and
> the tests from KDE's audio settings, with both intel and nvidia cards, to no
> avail. Alsamixer shows nothing muted except for S/PDIF (unmuting it changes
> nothing). When I try to play some sound, the system tray GUI volume indicator
> moves (showing changes in output volume),
> I use wireplumber, but this should be immaterial: in my understanding
> speaker-test is more low-level as it interfaces directly with ALSA.
>

Maybe you're missing some CS35l41 related options? 

Here's what I have:
CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_I2C=m

Created attachment 303825 [details]
Output of alsa-info script

I attached the output from alsa-info. I used to run the K1CN38WW BIOS and have just updated it to version K1CN40WW (no change). All the config flags are as you said:

$ zcat /proc/config.gz > file.config
$ cat file.config | grep CS35L41
CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_I2C=m

Created attachment 303826 [details]
lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-001.patch

Found the problem. Jacopo and I have slightly different revisions of the same laptop and therefore have different subsystem ID's.

Here's an updated patch that adds this revision's subsystem ID to use the quirk.

(In reply to Cameron Berkenpas from comment #63)
> Created attachment 303826 [details]
> lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-001.patch
> 
> Found the problem. Jacopo and I have slightly different revisions of the
> same laptop and therefore have different subsystem ID's.
> 
> Here's an updated patch that adds this revision's subsystem ID to use the
> quirk.

Now it works, this is the best! There's a little "click" sometimes when a sound starts playing, but I guess that's just a software glitch, as it goes away when trying to reproduce it.

Thank you Cameron, you really helped me!

See if the click occurs with all software. When it happens, try "dmesg 
-T" (to get a timestamp) and see if any messages line up.

I don't recall that happening to me, but I could just be tuning it out.

What I think might be happening... is that when there hasn't been any 
audio output for a while, the speakers/amp chips go to sleep and have to 
be woken back up. In such situations, I notice there's a small delay in 
audio output starting up again (probably a bit less than a second, but 
I've never tried to time it) so that could it. If that's the case, 
you'll likely see some output in dmesg corresponding to the CSC3551's 
being woken back up.

If you notice one speaker going out (or both), keep an eye out for "amp 
short" errors in dmesg. When those happen, you'll temporarily lose sound 
in the affected speakers... Eventually it will recover. When this is an 
issue, it's more likely to occur at high volumes (so worth looking for!).

There's no documentation in the code as to what these errors mean... but 
I think what's happening is that the amp chip has determined that 
whatever it's sending to the speaker is perhaps out of bounds so that's 
not good and probably you would want to avoid using the patch until we 
can figure something out. So definitely test this out. If you're able to 
play some music at a high volume for a couple of minutes without issue, 
I think you're safe from this particular "amp short" issue.

But this is very encouraging news! I'm glad we got this working for you! 
I think it's ridiculous that in 2023 we can't just have working sound in 
Linux on x86. I remember buying an ISA Soundblaster 16 in 1999 to ensure 
sound would work under Linux then having to pass parameters to the 
module such as the ioport, etc. We've come so far since then, but some 
vendors are still so obtuse about these things.

On 3/1/23 16:17, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #64 from Jacopo G. Chen (jacopo.chen256@gmail.com) ---
> (In reply to Cameron Berkenpas from comment #63)
>> Created attachment 303826 [details]
>> lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-001.patch
>>
>> Found the problem. Jacopo and I have slightly different revisions of the
>> same laptop and therefore have different subsystem ID's.
>>
>> Here's an updated patch that adds this revision's subsystem ID to use the
>> quirk.
> Now it works, this is the best! There's a little "click" sometimes when a
> sound
> starts playing, but I guess that's just a software glitch, as it goes away
> when
> trying to reproduce it.
>
> Thank you Cameron, you really helped me!
>

Created attachment 303828 [details]
lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch

This patch theoretically supports the following models:
+       SND_PCI_QUIRK(0x17aa, 0x3874, "Legion 7 16IAX7", ALC287_FIXUP_CS35L41_I2C_2),
+       SND_PCI_QUIRK(0x17aa, 0x386f, "Legion 7 16IAX7", ALC287_FIXUP_CS35L41_I2C_2),
+       SND_PCI_QUIRK(0x17aa, 0x3803, "Legion 7i slim 16IAH7", ALC287_FIXUP_CS35L41_I2C_2),
+       SND_PCI_QUIRK(0x17aa, 0x3856, "Yoga Slim 7 Carbon 14ACN6", ALC287_FIXUP_CS35L41_I2C_2),
+       SND_PCI_QUIRK(0x17aa, 0x3877, "Legion 7 slim 16ARHA7", ALC287_FIXUP_CS35L41_I2C_2),

The Lenovo Legion 7i Gen 7 16IAX7 seems pretty safe (and has had by far the most testing). 

That being said, all support provided by this patch is USE AT YOUR OWN RISK. Different models of laptop theoretically have different values (that should be provided via the DSD table in the BIOS). These are guessed values that work for the 16IAX7 and possibly others. I can't make any guarantees.

If you have problems with your sound, overly loud volume, distorted sound, "AMP short" errors (see below), back out the patch and update this bug with your feedback (giving your alsa-info)

If you get "AMP short" messages in dmesg, it's probably wise to back out the patch as I suspect prolonged usage could result. To test for this, just play some music out a very high volume for a few minutes. You may notice one or both of your speakers going out (and you'll see "AMP short" messages in dmesg). If this happens, back the patch out. 

With "AMP short" errors, once audio output has been stopped for probablly 5+ minutes, the affected speakers will "recover", but eventually they'll fail again. Just because they might start working again doesn't mean there isn't a serious problem. Just back out the patch and provide feedback.

If you don't get any sound at all... Provide your alsa-info and your full dmesg output. If you see a message such as "Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENOENT: Error requesting irq at index 0", this is an issue that occurs before my patch. There's an issue with the cs35l41 driver where it's not able to detect the CSC3551's on your model of laptop. Reporting this to Cirrus Logic may help and AFTER that issue is fixed... You may still need my patch.

If the patch works, please provide feedback with your alsa-info. With all the info, my hope is that we'll have an eventual "safe list" of laptop models for this patch.

Created attachment 303831 [details]
dmesg + alsa-info

Update: sound in general still works great (the nVidia sound card does not work but I think that's an alsa config issue). Clicks happen upon opening sound related apps like spotify but leave no trace on dmesg.
However, it appears that some errors are triggered in cs35l41_hda.c (functions: static int cs35l41_apply_calibration, static int cs35l41_smart_amp):

[    6.940102] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cannot Write Control: CAL_AMBIENT - 1
[    6.940971] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cannot Initialize Firmware. Error: 1

Not really an issue, I played loud music without speakers going out/short amp errors.

As a suggestion since this patch isn't likely to be accepted by the Cirrus driver maintainers in it's current form it might be best to open up a central place for you to work with people on it and iterate rather than this kernel bug tracker.

Maybe like a personal Github repo?

Yeah, those errors are expected. I get the same. It's due to the hackish 
nature of the patch.

I think the Nvidia sound is something that needs an external monitor to 
work (ie, via HDMI or displayport).

I'm a bit concerned by the clicks though... But unsure if that problem 
is serious.

On 3/2/23 07:34, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #67 from Jacopo G. Chen (jacopo.chen256@gmail.com) ---
> Created attachment 303831 [details]
>    --> https://bugzilla.kernel.org/attachment.cgi?id=303831&action=edit
> dmesg + alsa-info
>
> Update: sound in general still works great (the nVidia sound card does not
> work
> but I think that's an alsa config issue). Clicks happen upon opening sound
> related apps like spotify but leave no trace on dmesg.
> However, it appears that some errors are triggered in cs35l41_hda.c
> (functions:
> static int cs35l41_apply_calibration, static int cs35l41_smart_amp):
>
> [    6.940102] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cannot Write
> Control:
> CAL_AMBIENT - 1
> [    6.940971] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cannot Initialize
> Firmware. Error: 1
>
> Not really an issue, I played loud music without speakers going out/short amp
> errors.
>

Hello,

I've the issue with Lenovo Legion 7i but I don't know how to install these patches,
I'm a novice with linux please help me with steps

Thank you

You'll have to read up on how to compile a custom kernel for your 
distribution.

On 3/5/23 00:57, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> Olivier (onlinetwisto@gmail.com) changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |onlinetwisto@gmail.com
>
> --- Comment #70 from Olivier (onlinetwisto@gmail.com) ---
> Hello,
>
> I've the issue with Lenovo Legion 7i but I don't know how to install these
> patches,
> I'm a novice with linux please help me with steps
>
> Thank you
>

I wanted to confirm that I got this working for 16ARHA7 (Lenovo Legion 7 AMD)

I used the instructions here for archlinux (which is what I run):

https://wiki.archlinux.org/title/Kernel/Traditional_compilation

I just used this command to patch it after unzipping the kernel:

    make mrproper
    zcat /proc/config.gz  > .config
    patch -p1 < ./lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch 
    make -j$(nproc)
    make modules
    sudo make modules_install
    make bzImage


Then had to copy the kernel, make the initramfs and update the bootloader.

No problems with amp shorts so far, but I will watch it.

Created attachment 303877 [details]
attachment-26271-0.html

That's great news! If there are no problems over the next few months, 
please update us.

That being said... And this is for everyone: As Mario Limonciello 
suggested... At some point, this discussion and these patches should be 
moved out of this kernel bug.  Once I'm able to do that, I'll ask that 
people look for updated patches there as well as for providing status 
updates.

That's still a little ways off yet, as I'm a pretty busy guy (I was only 
able to do some more work on this because I was out sick recently). When 
the time comes, I'll update this bug with the new location.

On 3/5/2023 12:38 PM, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> antidense@gmail.com  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |antidense@gmail.com
>
> --- Comment #72 fromantidense@gmail.com  ---
> I wanted to confirm that I got this working for 16ARHA7 (Lenovo Legion 7 AMD)
>
> I used the instructions here for archlinux (which is what I run):
>
> https://wiki.archlinux.org/title/Kernel/Traditional_compilation
>
> I just used this command to patch it after unzipping the kernel:
>
>      make mrproper
>      zcat /proc/config.gz  > .config
>      patch -p1 < ./lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch
>      make -j$(nproc)
>      make modules
>      sudo make modules_install
>      make bzImage
>
>
> Then had to copy the kernel, make the initramfs and update the bootloader.
>
> No problems with amp shorts so far, but I will watch it.
>

(In reply to Cameron Berkenpas from comment #73)
> Created attachment 303877 [details]
> attachment-26271-0.html
> 
> That's great news! If there are no problems over the next few months, 
> please update us.
> 
> That being said... And this is for everyone: As Mario Limonciello 
> suggested... At some point, this discussion and these patches should be 
> moved out of this kernel bug.  Once I'm able to do that, I'll ask that 
> people look for updated patches there as well as for providing status 
> updates.
> 
> That's still a little ways off yet, as I'm a pretty busy guy (I was only 
> able to do some more work on this because I was out sick recently). When 
> the time comes, I'll update this bug with the new location.
> 
> On 3/5/2023 12:38 PM, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=216194
> >
> > antidense@gmail.com  changed:
> >
> >             What    |Removed                     |Added
> >
> ----------------------------------------------------------------------------
> >                   CC|                            |antidense@gmail.com
> >
> > --- Comment #72 fromantidense@gmail.com  ---
> > I wanted to confirm that I got this working for 16ARHA7 (Lenovo Legion 7
> AMD)
> >
> > I used the instructions here for archlinux (which is what I run):
> >
> > https://wiki.archlinux.org/title/Kernel/Traditional_compilation
> >
> > I just used this command to patch it after unzipping the kernel:
> >
> >      make mrproper
> >      zcat /proc/config.gz  > .config
> >      patch -p1 < ./lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch
> >      make -j$(nproc)
> >      make modules
> >      sudo make modules_install
> >      make bzImage
> >
> >
> > Then had to copy the kernel, make the initramfs and update the bootloader.
> >
> > No problems with amp shorts so far, but I will watch it.
> >

Hey Cameron, 

If you are still working on or looking into your alternate DSD patch, I noticed on my laptop below the Ctrl key it says "Audio By Harman". I looked them up and they produce speaker systems of all kinds, from laptop systems to bluetooth speakers, and so I wonder if they would be more forthcoming on the appropriate DSD info or verbs to send?

Just a thought, thank you for all you do,
Blake Lee

No, they can't help here.

The values are needed by the Cirrus Logic amplifier chips, and the 
values are specific to the model of laptop. These values depend on the 
type and setup of the speakers, and these details are largely unique to 
the model of laptop. Values that are way out of range relative to your 
model of laptop can potentially cause physical damage.

This is why Lenovo needs to do this. Only they have this information 
about their own laptop designs.

For the Lenovo 7i Gen 7, these values seem completely safe. No issues 
have developed since August or September (I forget which) since the 
initial version of the patch was released. I'm hoping these values that 
I've guessed are largely conservative to avoid as much risk as possible, 
but I really have no idea and this is why I'm clear this is a 
use-at-your-own-risk situation.

On 3/7/23 11:04, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> Blake Lee (blake99lee@gmail.com) changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |blake99lee@gmail.com
>
> --- Comment #74 from Blake Lee (blake99lee@gmail.com) ---
> (In reply to Cameron Berkenpas from comment #73)
>> Created attachment 303877 [details]
>> attachment-26271-0.html
>>
>> That's great news! If there are no problems over the next few months,
>> please update us.
>>
>> That being said... And this is for everyone: As Mario Limonciello
>> suggested... At some point, this discussion and these patches should be
>> moved out of this kernel bug.  Once I'm able to do that, I'll ask that
>> people look for updated patches there as well as for providing status
>> updates.
>>
>> That's still a little ways off yet, as I'm a pretty busy guy (I was only
>> able to do some more work on this because I was out sick recently). When
>> the time comes, I'll update this bug with the new location.
>>
>> On 3/5/2023 12:38 PM, bugzilla-daemon@kernel.org wrote:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>>>
>>> antidense@gmail.com  changed:
>>>
>>>              What    |Removed                     |Added
>>>
>> ----------------------------------------------------------------------------
>>>                    CC|                            |antidense@gmail.com
>>>
>>> --- Comment #72 fromantidense@gmail.com  ---
>>> I wanted to confirm that I got this working for 16ARHA7 (Lenovo Legion 7
>> AMD)
>>> I used the instructions here for archlinux (which is what I run):
>>>
>>> https://wiki.archlinux.org/title/Kernel/Traditional_compilation
>>>
>>> I just used this command to patch it after unzipping the kernel:
>>>
>>>       make mrproper
>>>       zcat /proc/config.gz  > .config
>>>       patch -p1 < ./lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch
>>>       make -j$(nproc)
>>>       make modules
>>>       sudo make modules_install
>>>       make bzImage
>>>
>>>
>>> Then had to copy the kernel, make the initramfs and update the bootloader.
>>>
>>> No problems with amp shorts so far, but I will watch it.
>>>
> Hey Cameron,
>
> If you are still working on or looking into your alternate DSD patch, I
> noticed
> on my laptop below the Ctrl key it says "Audio By Harman". I looked them up
> and
> they produce speaker systems of all kinds, from laptop systems to bluetooth
> speakers, and so I wonder if they would be more forthcoming on the
> appropriate
> DSD info or verbs to send?
>
> Just a thought, thank you for all you do,
> Blake Lee
>

Hello All :)
I jump in the conversation, which I was lurking for a while hoping for a patch to my Legion pro 7 16IRX8H . I guess it's too recent to receive any feedback on this model :O

Long story short, I tried n+1 combinations of possible solutions, with n->∞

I even opened a 3ed at Lenovo, https://forums.lenovo.com/t5/Ubuntu/Ubuntu-and-legion-pro-7-16IRX8H-audio-issues/m-p/5210709?page=1#5924344 , that they glossed over with much nonchalance by moving my post to the Linux pile of non working things.
My last resource was the wizardry made by Cameron by applying a patch to the lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch, namely adding the pci sound quirk for my sound card
	SND_PCI_QUIRK(0x17aa, 0x3846, "Legion 7 Pro 16IRX8H", ALC287_FIXUP_CS35L41_I2C_2),
hwinfo --sound reports:
Model: "Intel Audio device"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x7a50 
  SubVendor: pci 0x17aa "Lenovo"
  SubDevice: pci 0x3846 
...
Model: "nVidia Audio device"
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x22bc 
  SubVendor: pci 0xffff "Illegal Vendor ID"
  SubDevice: pci 0xffff 

Unfortunately, it doesn't work. If you have any idea or guide to rip these DSD info or verbs, I will try to contribute as much as I can.
PS, funny thing: I bought the laptop with no OS, so I can't say that my speakers are actually working -.-

Thanks a lot to everyone!

You're going to need some tools to grab the DSDT table. On Ubuntu you can do this with:
sudo apt install acpica-tools

# From there you can do:
mkdir /tmp/dsdt
cd /tmp/dsdt
sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
iasl -d dsdt.dat

# You should then have:
/tmp/dsdt/dsdt.dsl

Attach dsdt.dsl to this ticket and call it something like dsdt.dsl-16IRX8H so I can take a look at it.

If what you need is in there... you need a _very_ simple patch that will be accepted upstream. If not, probably need add support for your laptop to my hacked up patch.. and it will mean I'm definitely going for another brand of laptop next purchase.

Scratch that, I see you added your own quirk and it didn't work. You should attach your dmesg and provide the link to your alsa-info.

Created attachment 303959 [details]
legion pro 7 16IRX8H dsdt FILE

Hello Cameron, 
thanks a lot! What I've tested is actually using your patch and added in "patch_realtek.c"  section the 
	+SND_PCI_QUIRK(0x17aa, 0x3846, "Legion 7 Pro 16IRX8H", ALC287_FIXUP_CS35L41_I2C_2),
gathering the PCI address from  hwinfo --sound: 
Model: "Intel Audio device"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x7a50 
  SubVendor: pci 0x17aa "Lenovo"   <---- this 
  SubDevice: pci 0x3846 <----- This

 
I never used the /sys/firmware/acpi/tables/DSDT . So I have added it here. not sure how to use it though.

My alsa-info is here http://alsa-project.org/db/?f=ed0116e9d7235fd5cbece5dccaa589ecad71f534
And my dmesg is https://pastebin.mozilla.org/gjXQOg32

I really admire how much  effort you put into helping this community. 

Thanks again

Definitely need your alsa-info link.

It's possible this doesn't use Cirrus Logic.

On 3/15/23 2:25 PM, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #79 from Carlo Francesco (gentuser@gmail.com) ---
> Created attachment 303959 [details]
>    --> https://bugzilla.kernel.org/attachment.cgi?id=303959&action=edit
> legion pro 7 16IRX8H dsdt FILE
>

Created attachment 303960 [details]
alsa info from legion pro 7 16IRX8H

Created attachment 303961 [details]
Alsa info without any patch to the kernel

Sorry Cameron, this is the correct alsa-info

Created attachment 303962 [details]
attachment-14046-0.html

I think this is the relevant section, but I'm also not 100% sure and I'm 
pretty busy so I can't really check too thoroughly. We do see the 
"TIAS2781" show in your alsa-info though (but that's just showing your 
ACPI devices which we already know this is).

So far it's not looking like this laptop has Cirrus Logic AMP chips of 
any kind. From both the DSDT table and your alsa-info.

I strongly suspect there's no support for this hardware generally... 
Googling is turning up nothing.


             Scope (PC00.I2C2)
             {
                 Device (SPKR)
                 {
                     Name (_HID, "TIAS2781")  // _HID: Hardware ID
                     Name (_UID, Zero)  // _UID: Unique ID
                     Method (_SUB, 0, NotSerialized)  // _SUB: Subsystem ID
                     {
                         If ((SPID == Zero))
                         {
                             Return ("17AA3886")
                         }

                         If ((SPID == One))
                         {
                             Return ("17AA3884")
                         }
                     }

                     Method (_CRS, 0, NotSerialized)  // _CRS: Current 
Resource Settings
                     {
                         Name (RBUF, ResourceTemplate ()
                         {
                             I2cSerialBusV2 (0x003F, 
ControllerInitiated, 0x00061A80,
                                 AddressingMode7Bit, "\\_SB.PC00.I2C2",
                                 0x00, ResourceConsumer, , Exclusive,
                                 )
                             I2cSerialBusV2 (0x0038, 
ControllerInitiated, 0x00061A80,
                                 AddressingMode7Bit, "\\_SB.PC00.I2C2",
                                 0x00, ResourceConsumer, , Exclusive,
                                 )
                             I2cSerialBusV2 (0x0040, 
ControllerInitiated, 0x00061A80,
                                 AddressingMode7Bit, "\\_SB.PC00.I2C2",
                                 0x00, ResourceConsumer, , Exclusive,
                                 )
                             GpioIo (Exclusive, PullUp, 0x0000, 0x0000, 
IoRestrictionInputOnly,
                                 "\\_SB.GPI0", 0x00, ResourceConsumer, ,
                                 )
                                 {   // Pin list
                                     0x0000
                                 }
                             GpioInt (Edge, ActiveLow, SharedAndWake, 
PullNone, 0x0000,
                                 "\\_SB.GPI0", 0x00, ResourceConsumer, ,
                                 )
                                 {   // Pin list
                                     0x0000
                                 }
                         })
                         CreateWordField (RBUF, 0x9D, IN1N)
                         CreateWordField (RBUF, 0x7A, SIDN)
                         SIDN = GNUM (0x080A000D)
                         IN1N = GNUM (0x0805000B)
                         Return (RBUF) /* \_SB_.PC00.I2C2.SPKR._CRS.RBUF */
                     }

                     Method (_STA, 0, NotSerialized)  // _STA: Status
                     {
                         If ((MCSK == 0x02))
                         {
                             Return (0x0F)
                         }

                         Return (Zero)
                     }

                     Method (_DIS, 0, NotSerialized)  // _DIS: Disable 
Device
                     {
                     }
                 }

             }


One part stands up to me a bit:

                         If ((SPID == Zero))
                         {
                             Return ("17AA3886")
                         }

                         If ((SPID == One))
                         {
                             Return ("17AA3884")
                         }

17AA3884 matches the subsystem ID in your alsa-info:

Subsystem Id: 0x17aa3884


So probably we're in the right area... There's no 3886 in your 
alsa-info... But might be worth making sure you're selecting the correct 
audio output device?

Maybe "TIA" is the name of the company? I'm not finding anything relevant.

If Linux is important to you, I would take advantage of the 30 day 
return for your money back if all else fails.


Sadly, it looks like I will be very much skipping Lenovo on my next 
laptop (which isn't anytime soon anyway).


On 3/15/23 2:34 PM, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #80 from Carlo Francesco (gentuser@gmail.com) ---
> Hello Cameron,
> thanks a lot! What I've tested is actually using your patch and added in
> "patch_realtek.c"  section the
>          +SND_PCI_QUIRK(0x17aa, 0x3846, "Legion 7 Pro 16IRX8H",
> ALC287_FIXUP_CS35L41_I2C_2),
> gathering the PCI address from  hwinfo --sound:
> Model: "Intel Audio device"
>    Vendor: pci 0x8086 "Intel Corporation"
>    Device: pci 0x7a50
>    SubVendor: pci 0x17aa "Lenovo"   <---- this
>    SubDevice: pci 0x3846 <----- This
>
>
> I never used the /sys/firmware/acpi/tables/DSDT . So I have added it here.
> not
> sure how to use it though.
>
> My alsa-info is here
> http://alsa-project.org/db/?f=ed0116e9d7235fd5cbece5dccaa589ecad71f534
> And my dmesg ishttps://pastebin.mozilla.org/gjXQOg32
>
> I really admire how much  effort you put into helping this community.
>
> Thanks again
>

Seems to be no different.

On 3/15/23 14:51, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #83 from Carlo Francesco (gentuser@gmail.com) ---
> Created attachment 303961 [details]
>    --> https://bugzilla.kernel.org/attachment.cgi?id=303961&action=edit
> Alsa info without any patch to the kernel
>
> Sorry Cameron, this is the correct alsa-info
>

Indeed, I'm thinking to return the laptop. Totally not worth the high cost.

For the output device I can see I have:
Analog stereo duplex
Analog stereo output
Pro Audio

None of them works (headset are working)
i will google this tia thing
Thx :)

from : https://psref.lenovo.com/syspool/Sys/PDF/Legion/Legion_Pro_7_16IRX8H/Legion_Pro_7_16IRX8H_Spec.pdf

The laptop specs, in multimedia section it says:
Multi-Media
Audio Chip
High Definition (HD) Audio, Realtek® ALC3306 codec
Speakers
Stereo speakers (super linear speaker), 2W x2, audio by HARMAN certification, optimized with Nahimic Audio, Smart
Amplifier (AMP)

(identical to  the Legion 7 16IAX7 specs https://psref.lenovo.com/Product/Legion/Legion_7_16IAX7)

Yeah, but what is "Nahimic"? We don't get specific model numbers, seems 
relatively generic.

If and when you return it, make it extremely clear it's due to lack of 
Linux support of course. :)

If you find a good gaming laptop that works correctly with Linux that 
you're happy with, feel free to email me directly. Eventually I'll be on 
the market for one. :D

On 3/15/23 15:17, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #87 from Carlo Francesco (gentuser@gmail.com) ---
> from :
>
> https://psref.lenovo.com/syspool/Sys/PDF/Legion/Legion_Pro_7_16IRX8H/Legion_Pro_7_16IRX8H_Spec.pdf
>
> The laptop specs, in multimedia section it says:
> Multi-Media
> Audio Chip
> High Definition (HD) Audio, Realtek® ALC3306 codec
> Speakers
> Stereo speakers (super linear speaker), 2W x2, audio by HARMAN certification,
> optimized with Nahimic Audio, Smart
> Amplifier (AMP)
>
> (identical to  the Legion 7 16IAX7 specs
> https://psref.lenovo.com/Product/Legion/Legion_7_16IAX7)
>

I wrote this bash script to patch the current kernel with the patch (for archlinux).

This is my first time writing in bash, so hope there's nothing too egregious in it.
Feel free to suggest modifications.

https://github.com/antidense/archlinux-lenovo-legion-sound-patch/blob/main/kernel_compile.sh

I see one problem. The first line should be:
#!/bin/bash

You have:
!#/bin/bash

On 3/19/23 08:10, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #89 from antidense@gmail.com ---
> I wrote this bash script to patch the current kernel with the patch (for
> archlinux).
>
> This is my first time writing in bash, so hope there's nothing too egregious
> in
> it.
> Feel free to suggest modifications.
>
>
> https://github.com/antidense/archlinux-lenovo-legion-sound-patch/blob/main/kernel_compile.sh
>

Thanks to all (especially to Cameron)
Apparently my smart amp is not A cirrus logic. Very luckily is a Texas Instrument https://www.ti.com/product/TAS2781

For my TAS2781 smart amp there are even pin schemas on their website and drivers for linux: https://git.ti.com/cgit/tas2781-linux-drivers

Anyone could guide me on how to make the patch for this chip (before I get to destroy my amp and speakers ahah)

My laptop version is Lenovo Legion 16IRX8H
 
Thanks to all!

Fsck yeah! This is a great find!

You may have saved Lenovo at least one sale... If only the built-in nic 
had 2.5 Gbps like the Gen 7 model, but I never got that setup with my 
Gen 7 anyway (since my 10g switch doesn't support 2.5 Gps, and this is 
apparently the common case).

Anyway, I'm going to dig into this and if I start figuring some stuff 
out, I'll respond to you directly to keep from polluting this bug.

On 3/19/23 10:20, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #91 from Carlo Francesco (gentuser@gmail.com) ---
> Thanks to all (especially to Cameron)
> Apparently my smart amp is not A cirrus logic. Very luckily is a Texas
> Instrument https://www.ti.com/product/TAS2781
>
> For my TAS2781 smart amp there are even pin schemas on their website and
> drivers for linux: https://git.ti.com/cgit/tas2781-linux-drivers
>
> Anyone could guide me on how to make the patch for this chip (before I get to
> destroy my amp and speakers ahah)
>
> My laptop version is Lenovo Legion 16IRX8H
>
> Thanks to all!
>

Carlo,

I jumped for joy a little too soon. These are drivers in progress, and here's the latest version (I think):
https://mailman.alsa-project.org/hyperkitty/list/alsa-devel@alsa-project.org/message/ESCCDHAIMYA5LQ44L64ZC4OVTSBRHLKZ/

The problem is that these are ASoC drivers:
https://www.alsa-project.org/wiki/ASoC

This driver isn't enough to do anything on its own on your laptop I'm afraid.

This was exactly the case the cs35l41 drivers (which includes CSC3551 support). A callback was implemented for systems with cs35l41 smart amps so that they audio output would work.

Fortunately, one of the Cirrus Logic devs ended up purchasing the Lenovo Legion 7 Gen 6 (AMD version) and wanted his audio to work which helped to grease the wheels I think.

I would email the developers and see if they're working on anything or if there are at least plans to implement support.

Hopefully we don't end up with a situation where the smart amps are technically supported, but the BIOS doesn't have enough information for them to work, is the case with the Legion 7 Gen 7.

So definitely be mindful of your 30 day return period.

(In reply to Cameron Berkenpas from comment #92)
> Fsck yeah! This is a great find!
> 
> You may have saved Lenovo at least one sale... If only the built-in nic 
> had 2.5 Gbps like the Gen 7 model, but I never got that setup with my 
> Gen 7 anyway (since my 10g switch doesn't support 2.5 Gps, and this is 
> apparently the common case).
> 
> Anyway, I'm going to dig into this and if I start figuring some stuff 
> out, I'll respond to you directly to keep from polluting this bug.

Here's a thread where people are expressing their dissatisfaction with Lenovo's support of Linux on their Legion series laptops. Maybe if enough people chime in, they'll take us seriously and we'll get somewhere. I personally don't need/want formalized Linux support... I just want the hardware to work:
https://forums.lenovo.com/t5/Ubuntu/Ubuntu-and-legion-pro-7-16IRX8H-audio-issues/m-p/5210709

Thank you all, especially Cameron. His latest patch lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-001.patch works just like a charm. But one small note for one who will apply the patch to the latest (currently 6.2.7-arch1) kernel. You need manually copy paste the changes from the patch to the appropriate places of the files modified, cuz with the patch command it places changes in the wrong places.

Hi,

I've been working with the Legion team on this. I do want to highlight that Linux is not plan-of-record for this platform; but they have been working with the Lenovo Linux team to try and figure this out. This is our busiest time of year with our regular Linux certified platforms so patience and understanding is really appreciated :)

The Legion team just forwarded me the patch that is mentioned above as being required. I take it from the post that this is not all of the story and other pieces are missing? Can someone fill me in with as many details/specifics as possible - I want to make sure my asks of the team are as concise and detailed as possible.

No promises on a solution at this point - but the Legion team are engaged.

Thanks
Mark

The BIOS needs to include the proper programming for the amplifier for the Linux kernel driver to parse.

The patches that have been developed are workarounds with guessed values.  This isn't generically safe without knowing the proper values to utilize.

What are needed are the settings in the DSD table in the DSDT snippet shared on this ticket (and in my Lenovo forum) post. As Mario mentioned, the values are guessed. I suspect they're mostly safe values, however, I think they're still not quite right (max volume is lower than it should be). 

So perhaps a few of the guessed values are a bit off and/or some of the values that are optionally needed for the Legion 7i Gen 7i.

I believe these are all the properties that the driver can utilize from the DSDT:
https://github.com/gregkh/linux/blob/v6.2.9/sound/pci/hda/cs35l41_hda.c#L1322-L1366

Probably the Lenovo Smart AMP CSC3551 drivers are hard coding the values somewhere.

You can likely get some a bit of direction/help from Cirrus Logic. I just forwarded you the last email I received from them (you may need to check your spam filter).

Even if support doesnt work out for the Lenovo 7i Gen 7, your help is still greatly appreciated!

(In reply to Mark Pearson from comment #96)
> Hi,
> 
> I've been working with the Legion team on this. I do want to highlight that
> Linux is not plan-of-record for this platform; but they have been working
> with the Lenovo Linux team to try and figure this out. This is our busiest
> time of year with our regular Linux certified platforms so patience and
> understanding is really appreciated :)
> 
> The Legion team just forwarded me the patch that is mentioned above as being
> required. I take it from the post that this is not all of the story and
> other pieces are missing? Can someone fill me in with as many
> details/specifics as possible - I want to make sure my asks of the team are
> as concise and detailed as possible.
> 
> No promises on a solution at this point - but the Legion team are engaged.
> 
> Thanks
> Mark

(In reply to Mario Limonciello (AMD) from comment #97)
> The BIOS needs to include the proper programming for the amplifier for the
> Linux kernel driver to parse.
> 
> The patches that have been developed are workarounds with guessed values. 
> This isn't generically safe without knowing the proper values to utilize.

Additionally to what Cameron said, if you could pass along that the Lenovo Slim series (both Slim 7i Gen 7 and mine, the Slim 7 Gen 7 (AMD) ) have the same issue and likely the same fix with slightly different table entries, that would be great! This issue is across the whole current-gen Legion lineup.

(In reply to Mario Limonciello (AMD) from comment #97)
> The BIOS needs to include the proper programming for the amplifier for the
> Linux kernel driver to parse.
> 
> The patches that have been developed are workarounds with guessed values. 
> This isn't generically safe without knowing the proper values to utilize.

Additionally to what Cameron said, if you could pass along that the Lenovo Slim series (both Slim 7i Gen 7 and mine, the Slim 7 Gen 7 (AMD) ) have the same issue and likely the same fix with slightly different table entries, that would be great! This issue is across the whole current-gen Legion lineup.

(In reply to Mark Pearson from comment #96)
> Hi,
> 
> I've been working with the Legion team on this. I do want to highlight that
> Linux is not plan-of-record for this platform; but they have been working
> with the Lenovo Linux team to try and figure this out. This is our busiest
> time of year with our regular Linux certified platforms so patience and
> understanding is really appreciated :)
> 
> The Legion team just forwarded me the patch that is mentioned above as being
> required. I take it from the post that this is not all of the story and
> other pieces are missing? Can someone fill me in with as many
> details/specifics as possible - I want to make sure my asks of the team are
> as concise and detailed as possible.
> 
> No promises on a solution at this point - but the Legion team are engaged.
> 
> Thanks
> Mark

Additionally to what Cameron said, if you could pass along that the Lenovo Slim series (both Slim 7i Gen 7 and mine, the Slim 7 Gen 7 (AMD) ) have the same issue and likely the same fix with slightly different table entries, that would be great! This issue is across the whole current-gen Legion lineup.

(In reply to Blake Lee from comment #101)
> (In reply to Mark Pearson from comment #96)
> > Hi,
> > 
> > I've been working with the Legion team on this. I do want to highlight that
> > Linux is not plan-of-record for this platform; but they have been working
> > with the Lenovo Linux team to try and figure this out. This is our busiest
> > time of year with our regular Linux certified platforms so patience and
> > understanding is really appreciated :)
> > 
> > The Legion team just forwarded me the patch that is mentioned above as
> being
> > required. I take it from the post that this is not all of the story and
> > other pieces are missing? Can someone fill me in with as many
> > details/specifics as possible - I want to make sure my asks of the team are
> > as concise and detailed as possible.
> > 
> > No promises on a solution at this point - but the Legion team are engaged.
> > 
> > Thanks
> > Mark
> 
> Additionally to what Cameron said, if you could pass along that the Lenovo
> Slim series (both Slim 7i Gen 7 and mine, the Slim 7 Gen 7 (AMD) ) have the
> same issue and likely the same fix with slightly different table entries,
> that would be great! This issue is across the whole current-gen Legion
> lineup.

Seconding this, I have the Slim 7 Gen 7 AMD (16ARHA7) also and encountering this issue.

(In reply to Mark Pearson from comment #96)
> Hi,
> 
> I've been working with the Legion team on this. I do want to highlight that
> Linux is not plan-of-record for this platform; but they have been working
> with the Lenovo Linux team to try and figure this out. This is our busiest
> time of year with our regular Linux certified platforms so patience and
> understanding is really appreciated :)
> 
> The Legion team just forwarded me the patch that is mentioned above as being
> required. I take it from the post that this is not all of the story and
> other pieces are missing? Can someone fill me in with as many
> details/specifics as possible - I want to make sure my asks of the team are
> as concise and detailed as possible.
> 
> No promises on a solution at this point - but the Legion team are engaged.
> 
> Thanks
> Mark

Hi, I have a thinkbook 16p gen4 with the same ACL3306 and AMP (it's basically a re-skin of Legion slim 16). I wonder if Lenovo also has plan to provide BIOS support for this laptop model?

I recently purchased the lenovo legion 7i 16IAX7. I was happy to see linux almost work near entirely perfect on it - except for the speakers. 

I see there has been a kernel patch made by the amazing people here but I want to inquire before I try it how risky of an endeavor it is? I've read through the entire thread and it seems like some people have used it with this model ofaltop for almost a year now? How worried should I be about the prospect of it damaging my speakers. 

Second, what is the newest kernel version that the patch supports? 

I appreciate the time and help of everyone here.

(In reply to Vincent S. from comment #104)
> I recently purchased the lenovo legion 7i 16IAX7. I was happy to see linux
> almost work near entirely perfect on it - except for the speakers. 
> 
> I see there has been a kernel patch made by the amazing people here but I
> want to inquire before I try it how risky of an endeavor it is? I've read
> through the entire thread and it seems like some people have used it with
> this model ofaltop for almost a year now? How worried should I be about the
> prospect of it damaging my speakers. 
> 
> Second, what is the newest kernel version that the patch supports? 
> 
> I appreciate the time and help of everyone here.

I'm currently using it with kernel 6.3.2. As there hasn't been any problems with this patch and the 16IAX7 since I started using it back around August or September... I think the patch is fairly safe at this point. But it's still use-at-your-own risk of course.

(In reply to Cameron Berkenpas from comment #105)
> (In reply to Vincent S. from comment #104)
> > I recently purchased the lenovo legion 7i 16IAX7. I was happy to see linux
> > almost work near entirely perfect on it - except for the speakers. 
> > 
> > I see there has been a kernel patch made by the amazing people here but I
> > want to inquire before I try it how risky of an endeavor it is? I've read
> > through the entire thread and it seems like some people have used it with
> > this model ofaltop for almost a year now? How worried should I be about the
> > prospect of it damaging my speakers. 
> > 
> > Second, what is the newest kernel version that the patch supports? 
> > 
> > I appreciate the time and help of everyone here.
> 
> I'm currently using it with kernel 6.3.2. As there hasn't been any problems
> with this patch and the 16IAX7 since I started using it back around August
> or September... I think the patch is fairly safe at this point. But it's
> still use-at-your-own risk of course.

Hi, big thanks for your efforts! Lenovo really owes you a big one. I can confirm the patch also works on ThinkBook 16p gen4 IRH. The kernel version is 6.3.2. No amp short error in dmesg. I only added this line to your patch of sound/pci/hda/patch_realtek.c: "SND_PCI_QUIRK(0x17aa, 0x38ab, "Lenovo ThinkBook 16p Gen4 IRH", ALC287_FIXUP_CS35L41_I2C_2)"

Great to hear! Just keep an ear out for issues with your sound possibly 
developing over time.

Seeing as people with different models who have had success with this 
patch haven't reported issues... I wonder if maybe these are just really 
conservative settings? Under Linux, my sound tends to be more quiet than 
I'd like it to be, but not bad by any means, and certainly much better 
than no sound.

On 5/20/23 08:01, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
>
> --- Comment #106 from shuohuili (li012589li@outlook.com) ---
> (In reply to Cameron Berkenpas from comment #105)
>> (In reply to Vincent S. from comment #104)
>>> I recently purchased the lenovo legion 7i 16IAX7. I was happy to see linux
>>> almost work near entirely perfect on it - except for the speakers.
>>>
>>> I see there has been a kernel patch made by the amazing people here but I
>>> want to inquire before I try it how risky of an endeavor it is? I've read
>>> through the entire thread and it seems like some people have used it with
>>> this model ofaltop for almost a year now? How worried should I be about the
>>> prospect of it damaging my speakers.
>>>
>>> Second, what is the newest kernel version that the patch supports?
>>>
>>> I appreciate the time and help of everyone here.
>> I'm currently using it with kernel 6.3.2. As there hasn't been any problems
>> with this patch and the 16IAX7 since I started using it back around August
>> or September... I think the patch is fairly safe at this point. But it's
>> still use-at-your-own risk of course.
> Hi, big thanks for your efforts! Lenovo really owes you a big one. I can
> confirm the patch also works on ThinkBook 16p gen4 IRH. The kernel version is
> 6.3.2. No amp short error in dmesg. I only added this line to your patch of
> sound/pci/hda/patch_realtek.c: "SND_PCI_QUIRK(0x17aa, 0x38ab, "Lenovo
> ThinkBook
> 16p Gen4 IRH", ALC287_FIXUP_CS35L41_I2C_2)"
>

Thanks for all you guys!

I can confirm the sound could output at a acceptable level now at `Lenovo ThinkBook 16p Gen4 IRH` which is same as shuohuili.

Behavior change:
1. after install package named `sof-firmware` in Archlinux, the internal speaker can output sound on up facing speakers (but sound level is very low), but the down facing ones not work. (headphone jack and bluetooth works)

2. after applying the modified patch into kernel v6.3.4, the down facing speaker can output at a right level. (When I tried to adjust volume in Gnome settings, the low and middle volume seems `activate` down facing speakers and high volume `activate ` up facing speakers) (this means the sound level is not adjustable for now, but very funny though, ^_^)


Info:
1. Distro: Archlinux
2. Kernel version: 6.3.4
3. different from the path: (the second parameter has slight different from shuohuili's, this should pick up from alsa-info for specific machine even they may have same devive name, I guess)
    sound/pci/hda/patch_realtek.c: "SND_PCI_QUIRK(0x17aa, 0x38a9, "Lenovo ThinkBook 16p Gen4 IRH", ALC287_FIXUP_CS35L41_I2C_2)"

And hope this could be officially fixed up by Cirrus and Lenovo soon <https://lore.kernel.org/lkml/b4c202b2-ab29-e2aa-b141-0c967b2c1645@opensource.cirrus.com/>

Thanks again for all you guys!!! You are amazing!!!

Created attachment 304326 [details]
Volume comparison: patched linux/win11

Hi everyone, it occurred to me that since my Legion 7 16IAX7 also has Windows 11 in dual boot, I could test the speaker volume on both systems. This could help with calibration. I played a frequency sweep video on Youtube at 100% volume and used a spectrogram app on my phone, keeping it in the exact same position very close to the speakers.

I superimposed the two screenshots (attached), where red = Linux, green = Windows. The line records the max intensity ever reached at that frequency. Frequencies below 100 HZ should be disregarded as the video wasn't very loud there and it picked up some ambient noise.

I'm running Arch Linux with 6.3.2 patched kernel.