[PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Mauro Carvalho Chehab]

Newer Matebook D14 model comes with essx8336 and supports SOF,
but the initial models use the legacy driver, with a Realtek ALC 256
AC97 chip on it.

The BIOS seems to be prepared to be used by both models, so
it contains an entry for ESSX8336 on its DSDT table.

Add a quirk, as otherwise dspconfig driver will try to load
SOF, causing audio probe to fail.

Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
---
 sound/hda/intel-dsp-config.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
index 6a384b922e4f..8e728f0585dd 100644
--- a/sound/hda/intel-dsp-config.c
+++ b/sound/hda/intel-dsp-config.c
@@ -46,6 +46,22 @@ static const struct snd_soc_acpi_codecs __maybe_unused essx_83x6 = {
  * - the first successful match will win
  */
 static const struct config_entry config_table[] = {
+	/* Quirks */
+	{
+		.flags = 0,	/* Model uses AC97 with Realtek ALC 256 */
+		.device = PCI_DEVICE_ID_INTEL_HDA_CML_LP,
+		.dmi_table = (const struct dmi_system_id []) {
+			{
+				.ident = "Huawei NBLB-WAX9N",
+				.matches = {
+					DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
+					DMI_MATCH(DMI_PRODUCT_NAME, "NBLB-WAX9N"),
+				}
+			},
+			{}
+		}
+	},
+
 /* Merrifield */
 #if IS_ENABLED(CONFIG_SND_SOC_SOF_MERRIFIELD)
 	{
-- 
2.44.0

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Mauro Carvalho Chehab]

Em Thu, 18 Apr 2024 09:48:27 +0100
Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:

> Newer Matebook D14 model comes with essx8336 and supports SOF,
> but the initial models use the legacy driver, with a Realtek ALC 256
> AC97 chip on it.
> 
> The BIOS seems to be prepared to be used by both models, so
> it contains an entry for ESSX8336 on its DSDT table.
> 
> Add a quirk, as otherwise dspconfig driver will try to load
> SOF, causing audio probe to fail.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Worth to mention that I opened an issue on Github about that:

https://github.com/thesofproject/linux/issues/4934

I added there the ACPI DSDT table as a reference.


> ---
>  sound/hda/intel-dsp-config.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
> index 6a384b922e4f..8e728f0585dd 100644
> --- a/sound/hda/intel-dsp-config.c
> +++ b/sound/hda/intel-dsp-config.c
> @@ -46,6 +46,22 @@ static const struct snd_soc_acpi_codecs __maybe_unused essx_83x6 = {
>   * - the first successful match will win
>   */
>  static const struct config_entry config_table[] = {
> +	/* Quirks */
> +	{
> +		.flags = 0,	/* Model uses AC97 with Realtek ALC 256 */
> +		.device = PCI_DEVICE_ID_INTEL_HDA_CML_LP,
> +		.dmi_table = (const struct dmi_system_id []) {
> +			{
> +				.ident = "Huawei NBLB-WAX9N",
> +				.matches = {
> +					DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
> +					DMI_MATCH(DMI_PRODUCT_NAME, "NBLB-WAX9N"),
> +				}
> +			},
> +			{}
> +		}
> +	},
> +
>  /* Merrifield */
>  #if IS_ENABLED(CONFIG_SND_SOC_SOF_MERRIFIELD)
>  	{

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Pierre-Louis Bossart]

On 4/18/24 05:04, Mauro Carvalho Chehab wrote:
> Em Thu, 18 Apr 2024 09:48:27 +0100
> Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:
> 
>> Newer Matebook D14 model comes with essx8336 and supports SOF,
>> but the initial models use the legacy driver, with a Realtek ALC 256
>> AC97 chip on it.
>>
>> The BIOS seems to be prepared to be used by both models, so
>> it contains an entry for ESSX8336 on its DSDT table.
>>
>> Add a quirk, as otherwise dspconfig driver will try to load
>> SOF, causing audio probe to fail.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
> 
> Worth to mention that I opened an issue on Github about that:
> 
> https://github.com/thesofproject/linux/issues/4934
> 
> I added there the ACPI DSDT table as a reference.

This sounds like an 'easy enough' fix, but I don't have a burning desire
to start adding quirks of this nature. To be clear, the entire support
of the ES8336 is an absolute nightmare that I've stopped looking at
completely given the lack of support of vendor/OEMs.

In this case, the ACPI table is completely wrong, we should try to
'mark' the ES8336 device as 'not present' or detect the presence of HDaudio.

Andy, what do you think and what would be your recommendation?

>> ---
>>  sound/hda/intel-dsp-config.c | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
>> index 6a384b922e4f..8e728f0585dd 100644
>> --- a/sound/hda/intel-dsp-config.c
>> +++ b/sound/hda/intel-dsp-config.c
>> @@ -46,6 +46,22 @@ static const struct snd_soc_acpi_codecs __maybe_unused essx_83x6 = {
>>   * - the first successful match will win
>>   */
>>  static const struct config_entry config_table[] = {
>> +	/* Quirks */
>> +	{
>> +		.flags = 0,	/* Model uses AC97 with Realtek ALC 256 */
>> +		.device = PCI_DEVICE_ID_INTEL_HDA_CML_LP,
>> +		.dmi_table = (const struct dmi_system_id []) {
>> +			{
>> +				.ident = "Huawei NBLB-WAX9N",
>> +				.matches = {
>> +					DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
>> +					DMI_MATCH(DMI_PRODUCT_NAME, "NBLB-WAX9N"),
>> +				}
>> +			},
>> +			{}
>> +		}
>> +	},
>> +
>>  /* Merrifield */
>>  #if IS_ENABLED(CONFIG_SND_SOC_SOF_MERRIFIELD)
>>  	{

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Mauro Carvalho Chehab]

Em Thu, 18 Apr 2024 08:24:10 -0500
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> escreveu:

> On 4/18/24 05:04, Mauro Carvalho Chehab wrote:
> > Em Thu, 18 Apr 2024 09:48:27 +0100
> > Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:
> >   
> >> Newer Matebook D14 model comes with essx8336 and supports SOF,
> >> but the initial models use the legacy driver, with a Realtek ALC 256
> >> AC97 chip on it.
> >>
> >> The BIOS seems to be prepared to be used by both models, so
> >> it contains an entry for ESSX8336 on its DSDT table.
> >>
> >> Add a quirk, as otherwise dspconfig driver will try to load
> >> SOF, causing audio probe to fail.
> >>
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>  
> > 
> > Worth to mention that I opened an issue on Github about that:
> > 
> > https://github.com/thesofproject/linux/issues/4934
> > 
> > I added there the ACPI DSDT table as a reference.  
> 
> This sounds like an 'easy enough' fix, but I don't have a burning desire
> to start adding quirks of this nature. To be clear, the entire support
> of the ES8336 is an absolute nightmare that I've stopped looking at
> completely given the lack of support of vendor/OEMs.

Heh, I know the pain, having working myself to have some support for audio
on two different notebooks with my siblings, both with es8336. On both 
cases, the BIOS info was not really useful, requiring quirks to make device
to work properly.

This is btw a common issue I'm aware for a long time: BIOS data is
not reliable, as vendors tend to re-use BIOS from one device on others,
without actually reflecting what it is on each device.

The EDAC subsystem never relies on DMI data for memory banks - as even
server BIOS from top tear manufacturers usually report wrong data for
motherboard's DIMM labels. Instead, an userspace application reads
DMI data and propose changes, but patches for rasdaemon are required
to add such labels to a database.

-

In any case, this specific device doesn't have es8336 ;-)

Also, I don't think this problem will remain confined to es8336: any
other SOF driver may have the same problem: a BIOS (or a BIOS update)
may add non-existent _HID devices to DSDT, causing the driver to
disable AC97 support, enabling SOF instead and causing regressions.

As I wrote at the Github issue, one solution would be to do an I2C
scan to detect if the SOF device(s) reported by BIOS are really
present. This would require that, before calling 
snd_intel_acpi_dsp_driver_probe():

	- the I2C bus to be created;
	- Runtime PM for the audio device needs to put resume the
	  device and I2C bus controller, if suspended;
	- the I2C address of the audio device needs to be known
	  by sound/hda/intel-dsp-config.c

With that, a zero-byte (or one-byte if zero-byte not support)
read or write could detect if the device is there, before
initializing it - or calling the device-specific driver.

Another solution would be to probe the SOF driver, falling back
to AC97 if SOF init fails.

> 
> In this case, the ACPI table is completely wrong, we should try to
> 'mark' the ES8336 device as 'not present' or detect the presence of HDaudio.
> 
> Andy, what do you think and what would be your recommendation?
> 
> >> ---
> >>  sound/hda/intel-dsp-config.c | 16 ++++++++++++++++
> >>  1 file changed, 16 insertions(+)
> >>
> >> diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
> >> index 6a384b922e4f..8e728f0585dd 100644
> >> --- a/sound/hda/intel-dsp-config.c
> >> +++ b/sound/hda/intel-dsp-config.c
> >> @@ -46,6 +46,22 @@ static const struct snd_soc_acpi_codecs __maybe_unused essx_83x6 = {
> >>   * - the first successful match will win
> >>   */
> >>  static const struct config_entry config_table[] = {
> >> +	/* Quirks */
> >> +	{
> >> +		.flags = 0,	/* Model uses AC97 with Realtek ALC 256 */
> >> +		.device = PCI_DEVICE_ID_INTEL_HDA_CML_LP,
> >> +		.dmi_table = (const struct dmi_system_id []) {
> >> +			{
> >> +				.ident = "Huawei NBLB-WAX9N",
> >> +				.matches = {
> >> +					DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
> >> +					DMI_MATCH(DMI_PRODUCT_NAME, "NBLB-WAX9N"),
> >> +				}
> >> +			},
> >> +			{}
> >> +		}
> >> +	},
> >> +
> >>  /* Merrifield */
> >>  #if IS_ENABLED(CONFIG_SND_SOC_SOF_MERRIFIELD)
> >>  	{  

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Takashi Iwai]

On Thu, 18 Apr 2024 15:24:10 +0200,
Pierre-Louis Bossart wrote:
> 
> On 4/18/24 05:04, Mauro Carvalho Chehab wrote:
> > Em Thu, 18 Apr 2024 09:48:27 +0100
> > Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:
> > 
> >> Newer Matebook D14 model comes with essx8336 and supports SOF,
> >> but the initial models use the legacy driver, with a Realtek ALC 256
> >> AC97 chip on it.
> >>
> >> The BIOS seems to be prepared to be used by both models, so
> >> it contains an entry for ESSX8336 on its DSDT table.
> >>
> >> Add a quirk, as otherwise dspconfig driver will try to load
> >> SOF, causing audio probe to fail.
> >>
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
> > 
> > Worth to mention that I opened an issue on Github about that:
> > 
> > https://github.com/thesofproject/linux/issues/4934
> > 
> > I added there the ACPI DSDT table as a reference.
> 
> This sounds like an 'easy enough' fix, but I don't have a burning desire
> to start adding quirks of this nature. To be clear, the entire support
> of the ES8336 is an absolute nightmare that I've stopped looking at
> completely given the lack of support of vendor/OEMs.
> 
> In this case, the ACPI table is completely wrong, we should try to
> 'mark' the ES8336 device as 'not present' or detect the presence of HDaudio.
> 
> Andy, what do you think and what would be your recommendation?

This one is still pending, and I'd like to hear the decision from
Intel people.  Let me know if this hack is acceptable.


thanks,

Takashi

> 
> >> ---
> >>  sound/hda/intel-dsp-config.c | 16 ++++++++++++++++
> >>  1 file changed, 16 insertions(+)
> >>
> >> diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
> >> index 6a384b922e4f..8e728f0585dd 100644
> >> --- a/sound/hda/intel-dsp-config.c
> >> +++ b/sound/hda/intel-dsp-config.c
> >> @@ -46,6 +46,22 @@ static const struct snd_soc_acpi_codecs __maybe_unused essx_83x6 = {
> >>   * - the first successful match will win
> >>   */
> >>  static const struct config_entry config_table[] = {
> >> +	/* Quirks */
> >> +	{
> >> +		.flags = 0,	/* Model uses AC97 with Realtek ALC 256 */
> >> +		.device = PCI_DEVICE_ID_INTEL_HDA_CML_LP,
> >> +		.dmi_table = (const struct dmi_system_id []) {
> >> +			{
> >> +				.ident = "Huawei NBLB-WAX9N",
> >> +				.matches = {
> >> +					DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
> >> +					DMI_MATCH(DMI_PRODUCT_NAME, "NBLB-WAX9N"),
> >> +				}
> >> +			},
> >> +			{}
> >> +		}
> >> +	},
> >> +
> >>  /* Merrifield */
> >>  #if IS_ENABLED(CONFIG_SND_SOC_SOF_MERRIFIELD)
> >>  	{

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Andy Shevchenko]

On Mon, Apr 29, 2024 at 02:17:34PM +0200, Takashi Iwai wrote:
> On Thu, 18 Apr 2024 15:24:10 +0200,
> Pierre-Louis Bossart wrote:
> > On 4/18/24 05:04, Mauro Carvalho Chehab wrote:

...

> > Andy, what do you think and what would be your recommendation?
> 
> This one is still pending, and I'd like to hear the decision from
> Intel people.  Let me know if this hack is acceptable.

IIRC it was resolved on GitHub by Pierre, anything else I need to contribute?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Pierre-Louis Bossart]

On 4/29/24 07:25, Andy Shevchenko wrote:
> On Mon, Apr 29, 2024 at 02:17:34PM +0200, Takashi Iwai wrote:
>> On Thu, 18 Apr 2024 15:24:10 +0200,
>> Pierre-Louis Bossart wrote:
>>> On 4/18/24 05:04, Mauro Carvalho Chehab wrote:
> 
> ...
> 
>>> Andy, what do you think and what would be your recommendation?
>>
>> This one is still pending, and I'd like to hear the decision from
>> Intel people.  Let me know if this hack is acceptable.
> 
> IIRC it was resolved on GitHub by Pierre, anything else I need to contribute?

This initial patch was replaced by the one I sent on Friday
"[PATCH] ALSA: hda: intel-dsp-config: harden I2C/I2S codec detection"

I should have made it clearer in the commit message, sorry.

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Takashi Iwai]

On Mon, 29 Apr 2024 15:51:03 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> 
> On 4/29/24 07:25, Andy Shevchenko wrote:
> > On Mon, Apr 29, 2024 at 02:17:34PM +0200, Takashi Iwai wrote:
> >> On Thu, 18 Apr 2024 15:24:10 +0200,
> >> Pierre-Louis Bossart wrote:
> >>> On 4/18/24 05:04, Mauro Carvalho Chehab wrote:
> > 
> > ...
> > 
> >>> Andy, what do you think and what would be your recommendation?
> >>
> >> This one is still pending, and I'd like to hear the decision from
> >> Intel people.  Let me know if this hack is acceptable.
> > 
> > IIRC it was resolved on GitHub by Pierre, anything else I need to contribute?
> 
> This initial patch was replaced by the one I sent on Friday
> "[PATCH] ALSA: hda: intel-dsp-config: harden I2C/I2S codec detection"
> 
> I should have made it clearer in the commit message, sorry.

OK, thanks for the updates!


Takashi

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Andy Shevchenko]

On Thu, Apr 18, 2024 at 11:04:53AM +0100, Mauro Carvalho Chehab wrote:
> Em Thu, 18 Apr 2024 09:48:27 +0100
> Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:
> 
> > Newer Matebook D14 model comes with essx8336 and supports SOF,
> > but the initial models use the legacy driver, with a Realtek ALC 256
> > AC97 chip on it.
> > 
> > The BIOS seems to be prepared to be used by both models, so
> > it contains an entry for ESSX8336 on its DSDT table.
> > 
> > Add a quirk, as otherwise dspconfig driver will try to load
> > SOF, causing audio probe to fail.

...

> Worth to mention that I opened an issue on Github about that:
> 
> https://github.com/thesofproject/linux/issues/4934
> 
> I added there the ACPI DSDT table as a reference.

Yeah, please add a BugLink tag.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Takashi Iwai]

On Thu, 18 Apr 2024 16:06:00 +0200,
Andy Shevchenko wrote:
> 
> On Thu, Apr 18, 2024 at 11:04:53AM +0100, Mauro Carvalho Chehab wrote:
> > Em Thu, 18 Apr 2024 09:48:27 +0100
> > Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:
> > 
> > > Newer Matebook D14 model comes with essx8336 and supports SOF,
> > > but the initial models use the legacy driver, with a Realtek ALC 256
> > > AC97 chip on it.
> > > 
> > > The BIOS seems to be prepared to be used by both models, so
> > > it contains an entry for ESSX8336 on its DSDT table.
> > > 
> > > Add a quirk, as otherwise dspconfig driver will try to load
> > > SOF, causing audio probe to fail.
> 
> ...
> 
> > Worth to mention that I opened an issue on Github about that:
> > 
> > https://github.com/thesofproject/linux/issues/4934
> > 
> > I added there the ACPI DSDT table as a reference.
> 
> Yeah, please add a BugLink tag.

I thought a Link tag is preferred over a BugLink tag nowadays.

I can add it in my side, but let's wait for the review by Intel people
at first.


thanks,

Takashi

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Huawei Matebook D14 NBLB-WAX9N quirk detection

[Andy Shevchenko]

On Thu, Apr 18, 2024 at 09:48:27AM +0100, Mauro Carvalho Chehab wrote:
> Newer Matebook D14 model comes with essx8336 and supports SOF,
> but the initial models use the legacy driver, with a Realtek ALC 256
> AC97 chip on it.
> 
> The BIOS seems to be prepared to be used by both models, so
> it contains an entry for ESSX8336 on its DSDT table.
> 
> Add a quirk, as otherwise dspconfig driver will try to load
> SOF, causing audio probe to fail.

...

> +				.ident = "Huawei NBLB-WAX9N",
> +				.matches = {
> +					DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
> +					DMI_MATCH(DMI_PRODUCT_NAME, "NBLB-WAX9N"),
> +				}

I would leave a trailing comma to avoid unneeded churn in the future in case
this gets extended.

> +			},
> +			{}
> +		}

Ditto.

> +	},

-- 
With Best Regards,
Andy Shevchenko