Message-ID: <c72a2f28a6e5c2c3c9ed17269bd56e7484df960c.camel@ljones.dev>
Date:   Mon, 22 May 2023 09:35:40 +1200
From:   Luke Jones <luke@...nes.dev>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     linux-kernel@...r.kernel.org, tiwai@...e.com,
        sbinding@...nsource.cirrus.com, perex@...ex.cz,
        tangmeng@...ontech.com, andy.chi@...onical.com, p.jungkamp@....net,
        kasper93@...il.com, yangyuchi66@...il.com, armas@...ux.tech,
        ealex95@...il.com, james.schulman@...rus.com,
        david.rhodes@...rus.com, tanureal@...nsource.cirrus.com,
        rf@...nsource.cirrus.com, patches@...nsource.cirrus.com,
        alsa-devel@...a-project.org
Subject: Re: CSC3551 and devices missing related _DSD bits

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.

Powered by blists - more mailing lists