BUG] cs35l41-hda: OTP_BOOT_DONE timeout / I2C lost arbitration persists independent of bus speed (Lenovo Legion Slim 7 16APH8, BIOS M1CN48WW)

BUG] cs35l41-hda: OTP_BOOT_DONE timeout / I2C lost arbitration persists independent of bus speed (Lenovo Legion Slim 7 16APH8, BIOS M1CN48WW)

[KM.Plass]

Hi there.

System information
Machine: Lenovo Legion Slim 7 16APH8 (82Y4), AMD Ryzen 7 7840HS
BIOS version: M1CN48WW
Kernel: 7.0.0-31-generic (Ubuntu)
ACPI subsystem ID reported by driver: 17AA38B7
Audio codec: cs35l41-hda (I2C, ACPI HID "CSC3551"), 2 amplifiers at I2C 
addresses 0x40 and 0x41 on _SB.I2CD (i2c-designware controller instance 
AMDI0010:03)
Symptom

Both amplifier instances fail probe with:

cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Failed waiting for OTP_BOOT_DONE
cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: probe with driver cs35l41-hda 
failed with error -11
cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Failed waiting for OTP_BOOT_DONE
cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: probe with driver cs35l41-hda 
failed with error -11

occurring at the exact same timestamps as:

i2c_designware AMDI0010:03: i2c_dw_handle_tx_abort: lost arbitration

(repeated ~30 times within a few milliseconds, matching the probe attempts).

Internal speakers remain silent; headphones and Bluetooth audio work 
normally, isolating the problem to the internal CS35L41 amplifiers.

Background: a known fix for this exact SSID does not resolve the issue 
on this BIOS revision

A community-documented DSDT workaround exists for this exact model and 
subsystem ID (17AA38B7) on an earlier BIOS revision (M1CN42WW): lowering 
the I2C bus speed for both amplifiers from 1 MHz to 400 kHz in the DSDT 
resolves the "lost arbitration" failure there. Reference: 
https://forum.garudalinux.org/t/fix-lenovo-legion-slim-7-16aph8-82y4-silent-speakers-on-linux-cs35l41-at-400-khz/48722

On BIOS M1CN48WW this fix does NOT resolve the issue. I tested all of 
the following I2C bus speeds by patching the DSDT (I2cSerialBusV2 
resources for both 0x40 and 0x41 on _SB.I2CD) and loading the modified 
table via the kernel's initrd ACPI table-upgrade mechanism (confirmed 
successfully loaded via ACPI: DSDT ACPI table found in initrd, 
CONFIG_ACPI_TABLE_UPGRADE=y):

1 MHz (0x000F4240) - original firmware value - fails
400 kHz (0x00061A80) - matches the published M1CN42WW fix - fails 
identically
100 kHz (0x000186A0) - the speed the i2c-designware driver itself 
already force-downgrades AMDI0010:00 to, logged as "known not-working" 
at 400 kHz on that other bus instance - fails identically

All three speeds produce the exact same "lost arbitration" and "Failed 
waiting for OTP_BOOT_DONE" errors at the same point in boot. This 
strongly suggests I2C clock speed is not the (sole) root cause on this 
particular BIOS/board revision.

Kernel-side configuration checked

The cs35l41_hda_property.c table entry for this SSID appears correct:

{ "17AA38B7", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 1, 
-1, 0, 0, 0 },

reset_gpio_index = 0 correctly maps to the only GpioIo resource with 
IoRestrictionOutputOnly (ACPI pin 0x0082) among the GPIO resources 
appended to the device's _CRS (the SPK1 device has no _DSD at all; full 
_CRS excerpt below).

/sys/kernel/debug/gpio confirms this pin (#130) has already been claimed 
as an output by some consumer (shown as output with state low), so GPIO 
acquisition itself does not appear to be failing. dmesg contains no 
"Unable to get" / gpiod error messages related to this device or HID.

I was not able to determine, from userspace logs alone, whether the 
reset line is toggled with correct timing relative to the first I2C 
transaction (assertion duration / settle time before the driver attempts 
to talk to the amp) - this would require kernel-side GPIO tracing or a 
hardware logic analyzer, which I don't have access to.

Relevant ACPI _CRS excerpt (Device SPK1, decompiled DSDT)
Method (_CRS, 0, NotSerialized)
{
     Name (IBUF, ResourceTemplate ()
     {
         I2cSerialBusV2 (0x0040, ControllerInitiated, 0x000F4240,
             AddressingMode7Bit, "\_SB.I2CD", 0x00, ResourceConsumer, , 
Exclusive, )
         I2cSerialBusV2 (0x0041, ControllerInitiated, 0x000F4240,
             AddressingMode7Bit, "\_SB.I2CD", 0x00, ResourceConsumer, , 
Exclusive, )
     })
     Return (ConcatenateResTemplate (IBUF, GPIA))
}

Name (GPIA, ResourceTemplate ()
{
     GpioIo (Exclusive, PullNone, 0x0000, 0x0000, IoRestrictionOutputOnly,
         "\_SB.GPIO", 0x00, ResourceConsumer, , ) { 0x0082 }
     GpioIo (Exclusive, PullNone, 0x0000, 0x0000, IoRestrictionInputOnly,
         "\_SB.GPIO", 0x00, ResourceConsumer, , ) { 0x0055 }
     GpioIo (Shared, PullUp, 0x0064, 0x0000, IoRestrictionInputOnly,
         "\_SB.GPIO", 0x00, ResourceConsumer, , ) { 0x005A }
     GpioInt (Edge, ActiveLow, Shared, PullNone, 0x0064,
         "\_SB.GPIO", 0x00, ResourceConsumer, , ) { 0x005A }
})
Attachments to include when submitting
Full dmesg output from a boot with the original (1 MHz) DSDT
Full dmesg output from a boot with the 400 kHz DSDT test
Full dmesg output from a boot with the 100 kHz DSDT test
Full decompiled DSDT (iasl -d dsdt.aml) or at least the complete SPK1 
device block plus the _SB.I2CD scope
Question for maintainers

Is there a known timing/sequencing difference for CS35L41 reset handling 
on M1CN48WW (or in general for this board's GPIO controller / AMDI0010 
revision) that could cause "lost arbitration" independent of I2C clock 
speed? Could this point to an incorrect reset assertion duration or 
settle time rather than clock speed, and if so, is this adjustable from 
DSDT/userspace, or would it require a driver change (e.g. an additional 
delay after deasserting reset before the first OTP_BOOT_DONE poll)?

Happy to provide any additional logs, test patches, or run further tests 
on this hardware.

BTW: I'm not into computing, just tried to solve that problem using Claude.

RE: BUG] cs35l41-hda: OTP_BOOT_DONE timeout / I2C lost arbitration persists independent of bus speed (Lenovo Legion Slim 7 16APH8, BIOS M1CN48WW)

[Stefan Binding (Opensource)]

Hi,

Please create a bugzilla ticket at the below address and CC Cirrus Patches (patches@opensource.cirrus.com) to it, we will investigate the issue as soon as we can.

https://bugzilla.kernel.org/

Please attach an acpi dump and dmesg to the ticket.

Creating a public Bugzilla allows others with the same laptop to find relevant information pertaining to this issue.

Thanks,

Stefan

> -----Original Message-----
> From: KM.Plass <kmplass@pm.me>
> Sent: Sunday, September 6, 2026 10:17 PM
> To: linux-sound@vger.kernel.org
> Cc: sbinding@opensource.cirrus.com; tiwai@suse.de
> Subject: BUG] cs35l41-hda: OTP_BOOT_DONE timeout / I2C lost arbitration
> persists independent of bus speed (Lenovo Legion Slim 7 16APH8, BIOS
> M1CN48WW)
> 
> Hi there.
> 
> System information
> Machine: Lenovo Legion Slim 7 16APH8 (82Y4), AMD Ryzen 7 7840HS BIOS
> version: M1CN48WW
> Kernel: 7.0.0-31-generic (Ubuntu)
> ACPI subsystem ID reported by driver: 17AA38B7 Audio codec: cs35l41-hda
> (I2C, ACPI HID "CSC3551"), 2 amplifiers at I2C addresses 0x40 and 0x41 on
> _SB.I2CD (i2c-designware controller instance
> AMDI0010:03)
> Symptom
> 
> Both amplifier instances fail probe with:
> 
> cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Failed waiting for
> OTP_BOOT_DONE cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: probe with
> driver cs35l41-hda failed with error -11 cs35l41-hda i2c-CSC3551:00-cs35l41-
> hda.1: Failed waiting for OTP_BOOT_DONE cs35l41-hda i2c-CSC3551:00-
> cs35l41-hda.1: probe with driver cs35l41-hda failed with error -11
> 
> occurring at the exact same timestamps as:
> 
> i2c_designware AMDI0010:03: i2c_dw_handle_tx_abort: lost arbitration
> 
> (repeated ~30 times within a few milliseconds, matching the probe attempts).
> 
> Internal speakers remain silent; headphones and Bluetooth audio work
> normally, isolating the problem to the internal CS35L41 amplifiers.
> 
> Background: a known fix for this exact SSID does not resolve the issue on this
> BIOS revision
> 
> A community-documented DSDT workaround exists for this exact model and
> subsystem ID (17AA38B7) on an earlier BIOS revision (M1CN42WW):
> lowering the I2C bus speed for both amplifiers from 1 MHz to 400 kHz in the
> DSDT resolves the "lost arbitration" failure there. Reference:
> https://forum.garudalinux.org/t/fix-lenovo-legion-slim-7-16aph8-82y4-
> silent-speakers-on-linux-cs35l41-at-400-khz/48722
> 
> On BIOS M1CN48WW this fix does NOT resolve the issue. I tested all of the
> following I2C bus speeds by patching the DSDT (I2cSerialBusV2 resources for
> both 0x40 and 0x41 on _SB.I2CD) and loading the modified table via the
> kernel's initrd ACPI table-upgrade mechanism (confirmed successfully loaded
> via ACPI: DSDT ACPI table found in initrd,
> CONFIG_ACPI_TABLE_UPGRADE=y):
> 
> 1 MHz (0x000F4240) - original firmware value - fails
> 400 kHz (0x00061A80) - matches the published M1CN42WW fix - fails
> identically
> 100 kHz (0x000186A0) - the speed the i2c-designware driver itself already
> force-downgrades AMDI0010:00 to, logged as "known not-working"
> at 400 kHz on that other bus instance - fails identically
> 
> All three speeds produce the exact same "lost arbitration" and "Failed waiting
> for OTP_BOOT_DONE" errors at the same point in boot. This strongly suggests
> I2C clock speed is not the (sole) root cause on this particular BIOS/board
> revision.
> 
> Kernel-side configuration checked
> 
> The cs35l41_hda_property.c table entry for this SSID appears correct:
> 
> { "17AA38B7", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 1, -1,
> 0, 0, 0 },
> 
> reset_gpio_index = 0 correctly maps to the only GpioIo resource with
> IoRestrictionOutputOnly (ACPI pin 0x0082) among the GPIO resources
> appended to the device's _CRS (the SPK1 device has no _DSD at all; full _CRS
> excerpt below).
> 
> /sys/kernel/debug/gpio confirms this pin (#130) has already been claimed as
> an output by some consumer (shown as output with state low), so GPIO
> acquisition itself does not appear to be failing. dmesg contains no "Unable to
> get" / gpiod error messages related to this device or HID.
> 
> I was not able to determine, from userspace logs alone, whether the reset line
> is toggled with correct timing relative to the first I2C transaction (assertion
> duration / settle time before the driver attempts to talk to the amp) - this
> would require kernel-side GPIO tracing or a hardware logic analyzer, which I
> don't have access to.
> 
> Relevant ACPI _CRS excerpt (Device SPK1, decompiled DSDT) Method (_CRS,
> 0, NotSerialized) {
>      Name (IBUF, ResourceTemplate ()
>      {
>          I2cSerialBusV2 (0x0040, ControllerInitiated, 0x000F4240,
>              AddressingMode7Bit, "\_SB.I2CD", 0x00, ResourceConsumer, ,
> Exclusive, )
>          I2cSerialBusV2 (0x0041, ControllerInitiated, 0x000F4240,
>              AddressingMode7Bit, "\_SB.I2CD", 0x00, ResourceConsumer, ,
> Exclusive, )
>      })
>      Return (ConcatenateResTemplate (IBUF, GPIA)) }
> 
> Name (GPIA, ResourceTemplate ()
> {
>      GpioIo (Exclusive, PullNone, 0x0000, 0x0000, IoRestrictionOutputOnly,
>          "\_SB.GPIO", 0x00, ResourceConsumer, , ) { 0x0082 }
>      GpioIo (Exclusive, PullNone, 0x0000, 0x0000, IoRestrictionInputOnly,
>          "\_SB.GPIO", 0x00, ResourceConsumer, , ) { 0x0055 }
>      GpioIo (Shared, PullUp, 0x0064, 0x0000, IoRestrictionInputOnly,
>          "\_SB.GPIO", 0x00, ResourceConsumer, , ) { 0x005A }
>      GpioInt (Edge, ActiveLow, Shared, PullNone, 0x0064,
>          "\_SB.GPIO", 0x00, ResourceConsumer, , ) { 0x005A }
> })
> Attachments to include when submitting
> Full dmesg output from a boot with the original (1 MHz) DSDT Full dmesg
> output from a boot with the 400 kHz DSDT test Full dmesg output from a boot
> with the 100 kHz DSDT test Full decompiled DSDT (iasl -d dsdt.aml) or at least
> the complete SPK1 device block plus the _SB.I2CD scope Question for
> maintainers
> 
> Is there a known timing/sequencing difference for CS35L41 reset handling on
> M1CN48WW (or in general for this board's GPIO controller / AMDI0010
> revision) that could cause "lost arbitration" independent of I2C clock speed?
> Could this point to an incorrect reset assertion duration or settle time rather
> than clock speed, and if so, is this adjustable from DSDT/userspace, or would
> it require a driver change (e.g. an additional delay after deasserting reset
> before the first OTP_BOOT_DONE poll)?
> 
> Happy to provide any additional logs, test patches, or run further tests on this
> hardware.
> 
> BTW: I'm not into computing, just tried to solve that problem using Claude.
>