RE: Re: [PATCH] ALSA: hda/realtek: Fix internal speakers for Legion Y9000X 2022 IAH7

[Stefan Binding <sbinding@xxxxxxxxxxxxxxxxxxxxx>]

Hi,

To clarify, was the log you attached here using:
 	{ "17AA386E", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0,
0}, 0, 2, -1, 0, 0, 0 },
Or was it using your original value (index 1)?

The Speaker ID for this laptop should be index 2, if my ACPI for this
laptop is correct.
Both amps use the same GPIO for the interrupt line, thus the interrupt
is shared, and there is only a single interrupt line.
Disabling the interrupt on the second laptop is not a good idea, since
the interrupts are used to detect and recover from errors.

For further investigation, can you create a bugzilla ticket at the
below address and CC Cirrus Patches (patches@xxxxxxxxxxxxxxxxxxxxx) to
it.

https://bugzilla.kernel.org/

Can you also mention which distro you are using, as well which Kernel
you are using.
Also, can you please attach a dmesg of the error, as well as the
acpidump of your laptop.
($ acpidump > acpidump.out)
(You may need to install acpica-tools to do this)

Thanks,
Stefan

> -----Original Message-----
> From: ArcticLampyrid <ArcticLampyrid@xxxxxxxxxxx>
> Sent: Monday, April 15, 2024 5:50 PM
> To: sbinding@xxxxxxxxxxxxxxxxxxxxx
> Cc: ArcticLampyrid@xxxxxxxxxxx; david.rhodes@xxxxxxxxxx;
> james.schulman@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
> sound@xxxxxxxxxxxxxxx; patches@xxxxxxxxxxxxxxxxxxxxx;
> rf@xxxxxxxxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx
> Subject: Re: Re: [PATCH] ALSA: hda/realtek: Fix internal speakers
for Legion
> Y9000X 2022 IAH7
> 
> > According to the ACPI that I have access to, this is not correct -
the
> > Speaker ID is on index 2 not index 1.
> > Index 1 has a reference to the interrupt line. Therefore this
should be:
> >
> > 	{ "17AA386E", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0
> }, 0, 2, -1, 0, 0, 0 },
> 
> Sorry, but I'm unable to retrieve the speaker ID index from my BIOS.
> Please tell me how to check it, thanks.
> 
> I've tried using `spkid_gpio_index = 2`, but haven't noticed any
changes.
> 
> > The reason for any issue you see may be
> > because you have assigned the speaker id for the interrupt gpio in
ACPI
> > as mentioned above.
> 
> Despite changing `spkid_gpio_index` to 2, it hasn't worked with
> `generic_dsd_config`.
> 
> The journal logs show:
> ```log
> kernel: Serial bus multi instantiate pseudo device driver
CSC3551:00:
> Instantiated 2 I2C devices.
> kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Adding DSD
properties
> for 17AA386E
> kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Using extra _DSD
> properties, bypassing _DSD in ACPI
> kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic
CS35L41
> (35a40), Revision: B2
> kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Adding DSD
properties
> for 17AA386E
> kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Using extra _DSD
> properties, bypassing _DSD in ACPI
> kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy,
> assuming shared reset
> kernel: genirq: Flags mismatch irq 58. 00002088 (cs35l41 IRQ1
Controller)
> vs. 00002088 (cs35l41 IRQ1 Controller)
> kernel:  cs35l41_hda_probe+0x94b/0x9d0 [snd_hda_scodec_cs35l41
> 5706d5af6d4d4abb9d294b49d5cd4cc8a51aad9d]
> kernel:  ? __pfx_cs35l41_i2c_driver_init+0x10/0x10
> [snd_hda_scodec_cs35l41_i2c
> 8858b01ad506c8ac36ad9a656c7cb71d39d6ec09]
> kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Failed to request
IRQ
> 58 for cs35l41 IRQ1 Controller: -16
> kernel: cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed
with
> error -16
> ```
> 
> I believe this error might be caused by the configuration of the
same IRQ
> multiple times.
> 
> Additionally, I checked the Cirrus SmartAMP driver on Windows, which
> appears to use only one IRQ (ID 58) on my device.
> Therefore, I don't believe there is a need to configure two IRQs on
my
> device.
> 
> The message `Flags mismatch 00002088 vs. 00002088` is confusing.
> Further investigation reveals that the following check in
`__setup_irq`
> failed:
> ```c
> if (irqd_trigger_type_was_set(&desc->irq_data)) {
>     oldtype = irqd_get_trigger_type(&desc->irq_data);
> } else {
>     oldtype = new->flags & IRQF_TRIGGER_MASK;
>     irqd_set_trigger_type(&desc->irq_data, oldtype);
> }
> 
> if (!((old->flags & new->flags) & IRQF_SHARED) ||
>     (oldtype != (new->flags & IRQF_TRIGGER_MASK)))
>     goto mismatch;
> ```
> 
> While the previous request used flags `0x00002088 = IRQF_ONESHOT |
> IRQF_SHARED | IRQF_TRIGGER_LOW`,
> the `oldtype` was actually `IRQF_TRIGGER_RISING` (0x1) rather than
> `IRQF_TRIGGER_LOW` (0x8), leading to the mismatch.
> 
> I am new to Linux Kernel, not sure if this is expected behavior or a
bug for
> `IRQF_SHARED`.
> Ideally, a clearer message may be provided to facilitate
understanding.
> 
> Sorry to bother you if I make some foolish mistakes.