On Sat, 2023-05-20 at 10:14 +0200, Takashi Iwai wrote:
On Fri, 19 May 2023 00:26:22 +0200, Luke Jones wrote:
Hi Takashi (and all others),
We're beginning to encounter more and more laptops from ASUS in the ROG range where the bass speakers are connected to a cirrus amp, and the driver for cirrus is unable to pick this up due to being missing a _DSD section in the ACPI (SSDT). I've emailed engineers at ASUS I have contact with about this but it is unlikely that we will see corrections for each and every model + variant they have. The models we have seen so far are:
- GX650P
- GU604V
- GA402X
And there have been numerous forum postings in various places with the exact same issue for other models from ASUS that are not in the ROG group I deal with - oh and also some Lenovo and HP devices also.
Some of the logs are:
[ 5.542312] Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 I2C devices. [ 5.717261] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD Properties are missing for HID CSC3551. [ 5.717269] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error - EINVAL: Platform not supported [ 5.717286] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with error -22 [ 5.717734] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD Properties are missing for HID CSC3551. [ 5.717737] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error - EINVAL: Platform not supported [ 5.717750] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with error -22
and:
[ 3.343851] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD Properties are missing for HID CSC3551. [ 3.343854] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: error - EINVAL: Platform not supported [ 3.343855] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.0 failed with error -22 [ 3.345544] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD Properties are missing for HID CSC3551. [ 3.345546] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: error - EINVAL: Platform not supported [ 3.345548] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.1 failed with error -22
So there are SPI connected, and I2C connected.
Alex has already submitted the related patch_realtek work for the GU604V and no doubt there will be some follow up patches from myself or others for the other models. Alex has attempted to patch the Cirrus related parts in kernel direct with:
patch03_gu604v_speaker_acpi_hack.patch 2. https://github.com/bno1/linux-xanmod-gu604/blob/acpi-hack/ patch04_gu604v_spi_cs_gpio_hack.patch both of these patches have been tested and working for over a week.
From what I see the patch04_gu604v_spi_cs_gpio_hack patch needs to shift to
the cirrus driver sound/pci/hda/cs35l41_hda.c, and that driver must now have a quirk table - unless we can somehow add the cirrus related bits to the realtek code? I've personally not played with this beyond keeping an eye on it all and am reluctant to begin work on a solution until I've had some input on the direction it should take.
In any case, this is not an isolated issue and we could benefit from putting in place some quirk or similar to accommodate for laptops where the vendor for some reason does not include the _DSD parts for use with the cirrus driver. The trend is looking so far like this practice will continue regardless of the vendor.
Known reports:
- https://bugzilla.kernel.org/show_bug.cgi?id=216194
- https://www.spinics.net/lists/alsa-devel/msg146434.html
- https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff
- https://forums.linuxmint.com/viewtopic.php?t=392762
https://h30434.www3.hp.com/t5/Notebook-Operating-System-and-Recovery/Envy-x3...
The problem is that this can really easily blow up your machine if some incorrect bit is applied. And more easily applicable, more chance to break by novice users, simply by believing what a chat bot speaks :)
Yeah, it's an unfortunate issue for us. But I can't really see any alternative solution.
That's the very reason why this kind of change should be via ACPI table officially set up by the vendor. That said, the question is only who and how can be responsible for this kind of change. It's no technical issue, per se.
If BIOS can't be updated, at least, the configuration change has to be confirmed by ASUS people. If ASUS still ignores the inquires and requests, we may put the quirk but with a bit fat warning (and maybe complaints to ASUS) to be shown in the log as a very last resort.
I'm all for this.
Let's see what happens.
The list of laptops with this problem is growing. I've received word from my contacts that it is highly unlikely that new bios will be rolled out for each and every model + variant with the problem.
To put it in to scale, these are the laptops now known to have the missing _DSD, and does not include the others like Zenbook, or from other vendors: - G834J - GV302X - G614J - GX650P - GU604V - GA402X
Some of these may have a CPU variant, in which case this means an additional bios build. And they all have anywhere between 2-4 GPU variants which means bios builds for each CPU+GPU combination.
ASUS is not going to address this, so the only way forward I can see is to introduce a quirk that sets the pins etc *matched* to either the DMI board_name or the realtek codec which appears to be unique? I don't fully know about that so i defer to your judgement.
I can at least get some confirmation of pins from ASUS. This is much more manageable and justifiable to them than updating dozens and dozens of bios builds.
Can you suggest where I should start with implementing something like this? I can have it tested on all the laptops I listed above after getting verification from ASUS.
Cheers, Luke.