Important
THIS IS NOW OBSOLETE WITH KERNEL VERSIONS ≥ 6.7.0
A recent announcement in the kernel mail list by Cirrus developers will solve the problem described here. Therefore, the proposed solutions will be soon obsolete. See this comment (thanks, @flukejones, for the tip).
I got the speakers working on my Asus Zenbook 14 OLED UX3402, the one with Intel CPU and the two CS35L41
audio amplifiers connected over SPI (not the UM3402YA, with AMD and I²C). The amplifiers are supported by the snd_hda_scodec_cs35l41
module in recent kernel versions, but they require some model-specific configuration paramaters, that should be provided by the BIOS, via ACPI. Of course, they are missing. It seems that the Windows drivers have those parameters somehow hardcoded, instead of using ACPI (bad idea, but who am I to criticise). Since Asus has been nasty and refused/was not able to update the BIOS with the missing data, I have patched the ACPI tables myself.
Warning
As stated by Cirrus developers, if you try this there is a non-zero (low, I hope) possibility of blowing your speakers. Take into account that this procedure is not just configuring your box, it is hardware-level hacking with very scarce information about the hardware (thank you, ASUS, and thank you, Cirrus, for not publishing the CS35L41 datasheet and making it only available by request). Additionally, You should know how to work with DSDT or SSDT files (I have a brief guide here) and how to recover from a non booting system. You are on your own. You have been warned.
Note
I have used the patch for some months, and everything seems OK. As you can see, the most recent versions do not require electrical parameters to be specified, just providing the functions of several GPIO pins, that are already present in the original BIOS, and the behavior associated to them. I am almost sure that the patch is totally safe.
My BIOS is the most recent one (version 310). I have added two _DSD objects in the SSDT file
(ssdt_csc3551.dsl
, or its already assembled version, ssdt_csc3551.aml
):
-
One inside the SPK1 device, providing the missing
"cirrus,dev-index"
and other properties, just like the I2C models. You can also provide these properties by patching the kernel module (thelinux/sound/pci/hda/cs35l41_hda.c
file). -
Another one, after the SPK1 device, with the chip select GPIOs,
"cs-gpios"
, required by the SPI bus (the somehow simpler I²C bus does not use chip select pins, but addresses). Without this _DSD object, only one amplifier can be addressed and activated. In this case, the driver refuses to load even for this single working amplifier.
Instead of applying a SSDT file, you may patch the full DSDT dissassembled DSDT file (dsdt.dsl
).
This was my original solution (thanks to @thor2002ro for pointing to the simpler, nicer SSDT
solution, see the comment,
especially if you use grub). The patch is available for reference, just apply the SSDT file.
I keep the old, original patch, that produced AMP short error
messages when the volume was high
enough, for reference. Please try first the simpler patch with external boost, that seems to work
without flaws (thanks to @bdandy, see the comment).
Output from journalctl -b -g CSC3551 --output short-monotonic
after the old patch:
[5.358062] zenbook kernel: Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 SPI devices.
[5.643640] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[5.680302] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2
[5.996217] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Falling back to default firmware.
[5.996608] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: Firmware version: 3
[5.996611] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Jun 2022 14:55:56 GMT Daylight Time
[6.069598] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: Firmware: 400a4 vendor: 0x2 v0.58.0, 2 algorithms
[6.070173] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: 0: ID cd v29.78.0 XM@94 YM@e
[6.070185] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: 1: ID f20b v0.1.0 XM@17c YM@0
[6.070192] zenbook kernel: cs35l41-hda spi1-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
[6.083485] zenbook kernel: snd_hda_codec_realtek ehdaudio0D0: bound spi1-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
[6.083899] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Falling back to default firmware.
[6.083962] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: Firmware version: 3
[6.083966] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Jun 2022 14:55:56 GMT Daylight Time
[6.145224] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: Firmware: 400a4 vendor: 0x2 v0.58.0, 2 algorithms
[6.145817] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: 0: ID cd v29.78.0 XM@94 YM@e
[6.145828] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: 1: ID f20b v0.1.0 XM@17c YM@0
[6.145834] zenbook kernel: cs35l41-hda spi1-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
[6.161484] zenbook kernel: snd_hda_codec_realtek ehdaudio0D0: bound spi1-CSC3551:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
The "Falling back to default firmware" disappears if spk-id-gpios
are provided (the block is commented in the patch). As a result, a different firmware is loaded, resulting in very low volume and strong distortion. If the new patch is used, that uses external boost, the sound is correct, and the log is
[0.004000] zenbook kernel: ACPI: Table Upgrade: install [SSDT-CUSTOM- CSC3551]
[0.004000] zenbook kernel: ACPI: SSDT 0x00000000368FD000 0001A0 (v01 CUSTOM CSC3551 00000001 INTL 20200925)
[5.607253] zenbook kernel: Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 SPI devices.
[5.906936] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[5.907354] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
[5.938136] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2
[6.239406] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: Firmware version: 3
[6.239415] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431e02.wmfw: Fri 27 Aug 2021 14:58:19 W. Europe Daylight Time
[6.313109] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: Firmware: 400a4 vendor: 0x2 v0.43.1, 2 algorithms
[6.313524] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: 0: ID cd v29.63.1 XM@94 YM@e
[6.313530] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: 1: ID f20b v0.1.0 XM@176 YM@0
[6.313535] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: DSP1: spk-prot: C:\Users\tyang\Desktop\Product Setting\SmartAMP\ASUS\ASUS_Zenbook\UX3402\Tuning Release\220304\ASUS_UX3402_L_tuning_IDYC_ReDc_PICL_RTL_0304.bin
[6.337211] zenbook kernel: snd_hda_codec_realtek ehdaudio0D0: bound spi1-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
[6.337534] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: Firmware version: 3
[6.337540] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431e02.wmfw: Fri 27 Aug 2021 14:58:19 W. Europe Daylight Time
[6.399070] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: Firmware: 400a4 vendor: 0x2 v0.43.1, 2 algorithms
[6.399612] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: 0: ID cd v29.63.1 XM@94 YM@e
[6.399623] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: 1: ID f20b v0.1.0 XM@176 YM@0
[6.399629] zenbook kernel: cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: DSP1: spk-prot: C:\Users\tyang\Desktop\Product Setting\SmartAMP\ASUS\ASUS_Zenbook\UX3402\Tuning Release\220304\ASUS_UX3402_R_tuning_IDYC_ReDc_PICL_RTL_0304.bin
[6.427637] zenbook kernel: snd_hda_codec_realtek ehdaudio0D0: bound spi1-CSC3551:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
@staropram unfortunately I do not have anymore information, most of my cirrus knowladge comes from this thread, and luke's patch you have posted.
Correct, its mostly similar to Luke's patch, and to HP patch that Cirrus devs already added to the file. Minor differnces in pin configs
yes seems that the order of initialization. One may change which one is left, which is right, but seems matching
id
withindex
is correct way to goSome confusion here - both chips have
reset
pins, and both chips needchip select
pin.The pin number (Zero, One, 0x02 for .dsl, and
gpiod_get_index(physdev, NULL, XX, GPIOD_OUT_LOW);
- XX in kernel) represent order of pins in ACPI table. You first see x2 SPI/I2C identifiers, then followed by 4 or 5 pins definitions - these pins shall be allocated to functions.Last two pins are the same pin (check by hex number), which are also shared - this seems to be interrupt, and we do not need to allocated them. It leaves us with 3 pins (for most of you) or 2 pins (for my unlucky case) to allocated.
Seems that on all dual CS amps system reset line is shared. Reset line is output and it is active HIGH (electronics), so default state is PullDown (.dsl) or
GPIOD_OUT_LOW
(kernel). That means both chips would have the same entry ofcs35l41->reset_gpio = gpiod_get_index(physdev, NULL, 1, GPIOD_OUT_LOW);
for those who have reset pin 1st (seems that SPI devices have chip select pin 0th, while for I2C devices reset is 0th, but you guys already figured this one out :)Next, for SPI devices there shall be chip select pin. The way it works is the SPI controller has one native chip select, but you have two chips, so there need to be two pins to talk to two chips - one is used by default (SPI controller's native one), and it opens connection to 1st instance of driver (whichever device has
id
0). Second pin is generic motherboard pin which shall be allocated for SPI driver to know that - which is why you would require .dsl patch to addSPKR, Zero, Zero, Zero
- here 1st Zero you see is 0th pin from ACPI table. Easy way to tell which one it is that chip select is active low (again electronics), so default state would be PullUp/GPIOD_OUT_HIGH
. It is also an Output pin. Taking a glance at ACPI pins order, for devices with SPI its the 0th entry.Thus, in my patch i added the code
=> non-0 index (aka index=1) set chip select to 0th pin from ACPI table, in 'PullUp' mode. Strictly speaking probably even if you set it low instead, and same for reset, it would still work, as driver starts fast and switch them to correct mode. Doesn't hurt to be correct though. The reason 0th chip did not need to specify pin select is because every SPI master has one native chip select pin, and would use that one on its own, assuming its connected somewhere. For any more pins, someone has to inform it about.
Finally, in your cases guys, SPI devices have 5th pin, which in ACPI is indicated as InputOnly, meaning it can be used for reading data in - its index
0x02
for you. That is the only pin which can be used asspk-id
pin, and is also likely shared for both ICs. In my case, that pin is simply missing, similarly to HP device which Cirrus dev's already added. Which is why in my case I call internal function with different parameters (id of current chip, total number of chips, and negative pin number, so that it will not use external pin for that), which evaluated toSPK_ID=-19
, and loads firmware without_spkidX_
prefix in its name.To summarize, i believe all you have to do is to add my code extract above to all SPI powered devices (if you do it to I2C device, it will likely crash), without any modification, and it should just work without .dsl. Only exception would be if there is different pin order in ACPI table, but i believe with info i wrote above one shall be able to easily identify which pin is used for what