CSC3551 and devices missing related _DSD bits
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: 1. https://github.com/bno1/linux-xanmod-gu604/blob/acpi-hack/ 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...
Regards, Luke
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 :) 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.
Let's see what happens.
thanks,
Takashi
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.
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 :) 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.
Let's see what happens.
Thanks Takashi.
Just a note to say we're not ignoring this and are investigating the best way to support released laptops with ACPI incompatible with Linux. We're hoping this is going to be less of an issue going forward. Please bear with us while we look into this.
On Wed, 24 May 2023 18:36:04 +0200, Stuart Henderson wrote:
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 :) 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.
Let's see what happens.
Thanks Takashi.
Just a note to say we're not ignoring this and are investigating the best way to support released laptops with ACPI incompatible with Linux. We're hoping this is going to be less of an issue going forward. Please bear with us while we look into this.
Good to hear that you're working on it! Sure, it's no urgent issue and better wait for a proper solution.
thanks,
Takashi
On Wed, 2023-05-24 at 17:36 +0100, Stuart Henderson wrote:
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 :) 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.
Let's see what happens.
Thanks Takashi.
Just a note to say we're not ignoring this and are investigating the best way to support released laptops with ACPI incompatible with Linux. We're hoping this is going to be less of an issue going forward. Please bear with us while we look into this.
This is great news, thank you Stuart. If you need testing done at all on a wide range please reach out to me and I will enlist the help of those with the affected laptops I mentioned.
Hi Takashi, Hi Stuart (and of course, all others in here),
would you mind to evaluate this small (pseudo-)patch to be harmless? (concerning the blow-up theory the first answer in this converstion)
I won't push it upstream right now but I want to know if this patch might be harmfull. I'm owning a GA402XY myself and we digged out that the initial setting of the cr3551 can be done via:
diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c index 75020edd39e7..eaa06751bd48 100644 --- a/sound/pci/hda/cs35l41_hda.c +++ b/sound/pci/hda/cs35l41_hda.c @@ -1243,6 +1243,12 @@ static int cs35l41_no_acpi_dsd(struct cs35l41_hda *cs35l41, struct device *physd hw_cfg->bst_type = CS35L41_EXT_BOOST; hw_cfg->gpio1.func = CS35l41_VSPK_SWITCH; hw_cfg->gpio1.valid = true; + } else if (strncmp(hid, "CSC3551", 7) == 0 && strcmp(cs35l41-
acpi_subsystem_id, "10431463") == 0) {
+ // TESTING - (Hook for GA402X) + dev_warn(cs35l41->dev, "Warning: ASUS didn't provide the needed ACPI _DSD properties for GA402X series, using defaults.."); + hw_cfg->bst_type = CS35L41_EXT_BOOST; + hw_cfg->gpio1.func = CS35l41_VSPK_SWITCH; + hw_cfg->gpio1.valid = true; } else { /* * Note: CLSA010(0/1) are special cases which use a slightly different design.
--
Which for our devices(GA402XY) enables the DAC to be used (it's still quiet, as we don't know/set the right limits for boost/ind/cap at the moment).
The above will be called in our HDA_Quirk (sound/pci/hda/patch_realtek.c)
```pseudo [ALC285_FIXUP_ASUS_GA402XY] = { .type = HDA_FIXUP_FUNC, .v.func = cs35l41_fixup_i2c_two, // .... }, ```
The cs3551 init be loaded by the above quirk wich is bound to and checks its ID internally again(acpi_subsystem_id):
```pseudo SND_PCI_QUIRK(0x1043, 0x1463, "Asus Zephyrus G14 2023", ALC285_FIXUP_ASUS_GA402XY), ```
Many thanks in advance!
Best regards Armas
On Thu, 2023-05-25 at 09:30 +1200, Luke Jones wrote:
On Wed, 2023-05-24 at 17:36 +0100, Stuart Henderson wrote:
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 :) 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.
Let's see what happens.
Thanks Takashi.
Just a note to say we're not ignoring this and are investigating the best way to support released laptops with ACPI incompatible with Linux. We're hoping this is going to be less of an issue going forward. Please bear with us while we look into this.
This is great news, thank you Stuart. If you need testing done at all on a wide range please reach out to me and I will enlist the help of those with the affected laptops I mentioned.
Hi Takashi, Hi Stuart (and of course, all others in here),
would you mind to evaluate this small (pseudo-)patch to be harmless? (concerning the blow-up theory the first answer in this converstion)
I won't push it upstream right now but I want to know if this patch might be harmfull. I'm owning a GA402XY myself and we digged out that the initial setting of the cr3551 can be done via:
diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c index 75020edd39e7..eaa06751bd48 100644 --- a/sound/pci/hda/cs35l41_hda.c +++ b/sound/pci/hda/cs35l41_hda.c @@ -1243,6 +1243,12 @@ static int cs35l41_no_acpi_dsd(struct cs35l41_hda *cs35l41, struct device *physd hw_cfg->bst_type = CS35L41_EXT_BOOST; hw_cfg->gpio1.func = CS35l41_VSPK_SWITCH; hw_cfg->gpio1.valid = true;
- } else if (strncmp(hid, "CSC3551", 7) == 0 && strcmp(cs35l41-
acpi_subsystem_id, "10431463") == 0) {
// TESTING - (Hook for GA402X)dev_warn(cs35l41->dev, "Warning: ASUS didn't providethe needed ACPI _DSD properties for GA402X series, using defaults..");
hw_cfg->bst_type = CS35L41_EXT_BOOST;hw_cfg->gpio1.func = CS35l41_VSPK_SWITCH;hw_cfg->gpio1.valid = true;
- Note: CLSA010(0/1) are special cases which use a
slightly different design.
I wouldn't recommend making speculative changes like the above. There are no "default" values as these attributes describe the hardware for the particular device and these can be different on each SKU. In this case, it looks like the boost is being set incorrectly. We're looking into how we can support these older devices, so please bear with us while we investigate.
participants (4)
-
Armas Spann -
Luke Jones -
Stuart Henderson -
Takashi Iwai