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\)" <sbinding@opensource.cirrus.com>]

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.
>