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-x360-2022-13-b0074TU-Audio-not-working-in-Linux-Fedora/td-p/8644641
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:
> 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-x360-2022-13-b0074TU-Audio-not-working-in-Linux-Fedora/td-p/8644641
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:
> > 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-x360-2022-13-b0074TU-Audio-not-working-in-Linux-Fedora/td-p/8644641
>
> 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 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.
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.