[PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Allen Ballway]

This device has an audio card which is quirked for force SOF use but the
device does not support SOF so the card is not usable and audio can't
play through the HDMI output.

Add another quirk detection that matches the Azulle Access 4 in the DMI
info.

Signed-off-by: Allen Ballway <ballway@chromium.org>
---

 sound/hda/intel-dsp-config.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
index 6a384b922e4fa..cf4e25d031d56 100644
--- a/sound/hda/intel-dsp-config.c
+++ b/sound/hda/intel-dsp-config.c
@@ -142,7 +142,9 @@ static const struct config_entry config_table[] = {

 /*
  * Geminilake uses legacy HDAudio driver except for Google
- * Chromebooks and devices based on the ES8336 codec
+ * Chromebooks and devices based on the ES8336 codec. The Azulle Access 4
+ * uses the same audio card but does not support ES8336 and should use
+ * the legacy HDAudio driver.
  */
 /* Geminilake */
 #if IS_ENABLED(CONFIG_SND_SOC_SOF_GEMINILAKE)
@@ -159,6 +161,20 @@ static const struct config_entry config_table[] = {
 			{}
 		}
 	},
+	{
+		.flags = 0,
+		.device = PCI_DEVICE_ID_INTEL_HDA_GML,
+		.dmi_table = (const struct dmi_system_id []) {
+			{
+				.ident = "Azulle Access 4",
+				.matches = {
+					DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Azulle"),
+					DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Access4"),
+				}
+			},
+		{}
+		}
+	},
 	{
 		.flags = FLAG_SOF,
 		.device = PCI_DEVICE_ID_INTEL_HDA_GML,
--
2.45.0.rc0.197.gbae5840b3b-goog

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Pierre-Louis Bossart]

On 4/30/24 16:28, Allen Ballway wrote:
> This device has an audio card which is quirked for force SOF use but the
> device does not support SOF so the card is not usable and audio can't
> play through the HDMI output.
> 
> Add another quirk detection that matches the Azulle Access 4 in the DMI
> info.

Please try the patch "ALSA: hda: intel-dsp-config: harden I2C/I2S codec
detection" shared last week.

https://lore.kernel.org/linux-sound/20240426152818.38443-1-pierre-louis.bossart@linux.intel.com/

I really don't want to maintain a long list of ES8336 false detections
due to broken ACPI tables.

Thanks!

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Allen Ballway]

On Tue, Apr 30, 2024 at 2:46 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
>
> On 4/30/24 16:28, Allen Ballway wrote:
> > This device has an audio card which is quirked for force SOF use but the
> > device does not support SOF so the card is not usable and audio can't
> > play through the HDMI output.
> >
> > Add another quirk detection that matches the Azulle Access 4 in the DMI
> > info.
>
> Please try the patch "ALSA: hda: intel-dsp-config: harden I2C/I2S codec
> detection" shared last week.
>
> https://lore.kernel.org/linux-sound/20240426152818.38443-1-pierre-louis.bossart@linux.intel.com/
>
> I really don't want to maintain a long list of ES8336 false detections
> due to broken ACPI tables.
>
> Thanks!

Unfortunately the above patch didn't fix the issue, nor did I see any
of the change logs in dmesg.
Are there other alternative solutions or information I could gather to
make a more general solution?

Thanks,
Allen

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Pierre-Louis Bossart]

> Unfortunately the above patch didn't fix the issue, nor did I see any
> of the change logs in dmesg.
> Are there other alternative solutions or information I could gather to
> make a more general solution?

File an issue here: https://github.com/thesofproject/linux/issues

and attach the NHLT table:

sudo cat /sys/firmware/acpi/tables/NHLT > nhtl.dat; gzip nhlt.dat

as well as the results of alsa-info.

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Allen Ballway]

I filed a bug and after sharing the requested information it looks
like this device won't work on SOF without vendor support. Given this,
would the original patch returning this device to using HDAudio be
reasonable, or is there an preferred alternative to force this device
into using HDAudio?

Thanks,
Allen

On Mon, May 6, 2024 at 11:02 AM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
>
>
> > Unfortunately the above patch didn't fix the issue, nor did I see any
> > of the change logs in dmesg.
> > Are there other alternative solutions or information I could gather to
> > make a more general solution?
>
> File an issue here: https://github.com/thesofproject/linux/issues
>
> and attach the NHLT table:
>
> sudo cat /sys/firmware/acpi/tables/NHLT > nhtl.dat; gzip nhlt.dat
>
> as well as the results of alsa-info.

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Amadeusz Sławiński]

On 6/20/2024 9:27 PM, Allen Ballway wrote:
> I filed a bug and after sharing the requested information it looks
> like this device won't work on SOF without vendor support. Given this,
> would the original patch returning this device to using HDAudio be
> reasonable, or is there an preferred alternative to force this device
> into using HDAudio?
> 

And can you share link to the issue on mailing list, so someone reading 
this thread in the future doesn't have to guess where it is? ;)

Thanks,
Amadeusz

>>
>>> Unfortunately the above patch didn't fix the issue, nor did I see any
>>> of the change logs in dmesg.
>>> Are there other alternative solutions or information I could gather to
>>> make a more general solution?
>>
>> File an issue here: https://github.com/thesofproject/linux/issues
>>
>> and attach the NHLT table:
>>
>> sudo cat /sys/firmware/acpi/tables/NHLT > nhtl.dat; gzip nhlt.dat
>>
>> as well as the results of alsa-info.
> 

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Pierre-Louis Bossart]

On 6/21/24 08:15, Amadeusz Sławiński wrote:
> On 6/20/2024 9:27 PM, Allen Ballway wrote:
>> I filed a bug and after sharing the requested information it looks
>> like this device won't work on SOF without vendor support. Given this,
>> would the original patch returning this device to using HDAudio be
>> reasonable, or is there an preferred alternative to force this device
>> into using HDAudio?
>>
> 
> And can you share link to the issue on mailing list, so someone reading
> this thread in the future doesn't have to guess where it is? ;)

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

I don't know what to do with this configuration.
We added a quirk to force SOF to be used for ES8336 devices. It worked
for some, but not for others. Now we have quite a few ES8336-based
platforms that are broken with zero support from the vendor, with
obscure I2C/GPIO/clk issues.
Are we going to tag each one of them and say 'not supported, use HDMI only'?
That's pushing a bit the notion of quirk...It would generate an endless
stream of patches. The alternative is to do nothing and ask that those
platforms revert to HDMI audio only with a kernel parameter. That latter
alternative has my vote.

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Guenter Roeck]

On Fri, Jun 21, 2024 at 10:35:31AM +0200, Pierre-Louis Bossart wrote:
> 
> 
> On 6/21/24 08:15, Amadeusz Sławiński wrote:
> > On 6/20/2024 9:27 PM, Allen Ballway wrote:
> >> I filed a bug and after sharing the requested information it looks
> >> like this device won't work on SOF without vendor support. Given this,
> >> would the original patch returning this device to using HDAudio be
> >> reasonable, or is there an preferred alternative to force this device
> >> into using HDAudio?
> >>
> > 
> > And can you share link to the issue on mailing list, so someone reading
> > this thread in the future doesn't have to guess where it is? ;)
> 
> https://github.com/thesofproject/linux/issues/4981
> 
> I don't know what to do with this configuration.
> We added a quirk to force SOF to be used for ES8336 devices. It worked
> for some, but not for others. Now we have quite a few ES8336-based
> platforms that are broken with zero support from the vendor, with
> obscure I2C/GPIO/clk issues.
> Are we going to tag each one of them and say 'not supported, use HDMI only'?
> That's pushing a bit the notion of quirk...It would generate an endless
> stream of patches. The alternative is to do nothing and ask that those
> platforms revert to HDMI audio only with a kernel parameter. That latter
> alternative has my vote.
> 

Given that this apparently does not work for many ES8336 devices,
would it make more sense to disable SOF support for those by default
and _enable_ them with a kernel parameter ?

Guenter

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Pierre-Louis Bossart]

On 6/25/24 23:37, Guenter Roeck wrote:
> On Fri, Jun 21, 2024 at 10:35:31AM +0200, Pierre-Louis Bossart wrote:
>>
>>
>> On 6/21/24 08:15, Amadeusz Sławiński wrote:
>>> On 6/20/2024 9:27 PM, Allen Ballway wrote:
>>>> I filed a bug and after sharing the requested information it looks
>>>> like this device won't work on SOF without vendor support. Given this,
>>>> would the original patch returning this device to using HDAudio be
>>>> reasonable, or is there an preferred alternative to force this device
>>>> into using HDAudio?
>>>>
>>>
>>> And can you share link to the issue on mailing list, so someone reading
>>> this thread in the future doesn't have to guess where it is? ;)
>>
>> https://github.com/thesofproject/linux/issues/4981
>>
>> I don't know what to do with this configuration.
>> We added a quirk to force SOF to be used for ES8336 devices. It worked
>> for some, but not for others. Now we have quite a few ES8336-based
>> platforms that are broken with zero support from the vendor, with
>> obscure I2C/GPIO/clk issues.
>> Are we going to tag each one of them and say 'not supported, use HDMI only'?
>> That's pushing a bit the notion of quirk...It would generate an endless
>> stream of patches. The alternative is to do nothing and ask that those
>> platforms revert to HDMI audio only with a kernel parameter. That latter
>> alternative has my vote.
>>
> 
> Given that this apparently does not work for many ES8336 devices,
> would it make more sense to disable SOF support for those by default
> and _enable_ them with a kernel parameter ?

Some configurations work, so we would break them.

We tried to improve things by using ACPI information, but it turns out
some of the information is broken as well, so it's a multi-level chase
to figure out how the codec is wired (GPIOs mainly).

There's no good solution here.

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Guenter Roeck]

On 6/26/24 00:04, Pierre-Louis Bossart wrote:
> 
> 
> On 6/25/24 23:37, Guenter Roeck wrote:
>> On Fri, Jun 21, 2024 at 10:35:31AM +0200, Pierre-Louis Bossart wrote:
>>>
>>>
>>> On 6/21/24 08:15, Amadeusz Sławiński wrote:
>>>> On 6/20/2024 9:27 PM, Allen Ballway wrote:
>>>>> I filed a bug and after sharing the requested information it looks
>>>>> like this device won't work on SOF without vendor support. Given this,
>>>>> would the original patch returning this device to using HDAudio be
>>>>> reasonable, or is there an preferred alternative to force this device
>>>>> into using HDAudio?
>>>>>
>>>>
>>>> And can you share link to the issue on mailing list, so someone reading
>>>> this thread in the future doesn't have to guess where it is? ;)
>>>
>>> https://github.com/thesofproject/linux/issues/4981
>>>
>>> I don't know what to do with this configuration.
>>> We added a quirk to force SOF to be used for ES8336 devices. It worked
>>> for some, but not for others. Now we have quite a few ES8336-based
>>> platforms that are broken with zero support from the vendor, with
>>> obscure I2C/GPIO/clk issues.
>>> Are we going to tag each one of them and say 'not supported, use HDMI only'?
>>> That's pushing a bit the notion of quirk...It would generate an endless
>>> stream of patches. The alternative is to do nothing and ask that those
>>> platforms revert to HDMI audio only with a kernel parameter. That latter
>>> alternative has my vote.
>>>
>>
>> Given that this apparently does not work for many ES8336 devices,
>> would it make more sense to disable SOF support for those by default
>> and _enable_ them with a kernel parameter ?
> 
> Some configurations work, so we would break them.
> 

Yes, but for others it is a regression, so arguably the change to force-enable
SOF caused a regression and should either be reverted or fixed such that all
previously working configurations still work (even more so since fixing
the problem one-by-one as affected systems are found is being rejected).

Thanks,
Guenter

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Pierre-Louis Bossart]

On 6/26/24 15:09, Guenter Roeck wrote:
> On 6/26/24 00:04, Pierre-Louis Bossart wrote:
>>
>>
>> On 6/25/24 23:37, Guenter Roeck wrote:
>>> On Fri, Jun 21, 2024 at 10:35:31AM +0200, Pierre-Louis Bossart wrote:
>>>>
>>>>
>>>> On 6/21/24 08:15, Amadeusz Sławiński wrote:
>>>>> On 6/20/2024 9:27 PM, Allen Ballway wrote:
>>>>>> I filed a bug and after sharing the requested information it looks
>>>>>> like this device won't work on SOF without vendor support. Given
>>>>>> this,
>>>>>> would the original patch returning this device to using HDAudio be
>>>>>> reasonable, or is there an preferred alternative to force this device
>>>>>> into using HDAudio?
>>>>>>
>>>>>
>>>>> And can you share link to the issue on mailing list, so someone
>>>>> reading
>>>>> this thread in the future doesn't have to guess where it is? ;)
>>>>
>>>> https://github.com/thesofproject/linux/issues/4981
>>>>
>>>> I don't know what to do with this configuration.
>>>> We added a quirk to force SOF to be used for ES8336 devices. It worked
>>>> for some, but not for others. Now we have quite a few ES8336-based
>>>> platforms that are broken with zero support from the vendor, with
>>>> obscure I2C/GPIO/clk issues.
>>>> Are we going to tag each one of them and say 'not supported, use
>>>> HDMI only'?
>>>> That's pushing a bit the notion of quirk...It would generate an endless
>>>> stream of patches. The alternative is to do nothing and ask that those
>>>> platforms revert to HDMI audio only with a kernel parameter. That
>>>> latter
>>>> alternative has my vote.
>>>>
>>>
>>> Given that this apparently does not work for many ES8336 devices,
>>> would it make more sense to disable SOF support for those by default
>>> and _enable_ them with a kernel parameter ?
>>
>> Some configurations work, so we would break them.
>>
> 
> Yes, but for others it is a regression, so arguably the change to
> force-enable
> SOF caused a regression and should either be reverted or fixed such that
> all
> previously working configurations still work (even more so since fixing
> the problem one-by-one as affected systems are found is being rejected).

If you disable SOF, all you get with snd-hda-intel is HDMI outputs.
There is no alternative if you want local speakers, mic and jack
support, or extensions based on I2S.

Some of my Intel colleagues have an ES8336-based platform that works for
them, they successfully modified the sof_es8336 machine driver to add
HDMI support, so why would we disable a working config?

I would really err on the side of "if you contributed a working config,
or helped enable a working config, it will be maintained in the kernel".

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Takashi Iwai]

On Wed, 26 Jun 2024 15:09:34 +0200,
Guenter Roeck wrote:
> 
> On 6/26/24 00:04, Pierre-Louis Bossart wrote:
> > 
> > 
> > On 6/25/24 23:37, Guenter Roeck wrote:
> >> On Fri, Jun 21, 2024 at 10:35:31AM +0200, Pierre-Louis Bossart wrote:
> >>> 
> >>> 
> >>> On 6/21/24 08:15, Amadeusz Sławiński wrote:
> >>>> On 6/20/2024 9:27 PM, Allen Ballway wrote:
> >>>>> I filed a bug and after sharing the requested information it looks
> >>>>> like this device won't work on SOF without vendor support. Given this,
> >>>>> would the original patch returning this device to using HDAudio be
> >>>>> reasonable, or is there an preferred alternative to force this device
> >>>>> into using HDAudio?
> >>>>> 
> >>>> 
> >>>> And can you share link to the issue on mailing list, so someone reading
> >>>> this thread in the future doesn't have to guess where it is? ;)
> >>> 
> >>> https://github.com/thesofproject/linux/issues/4981
> >>> 
> >>> I don't know what to do with this configuration.
> >>> We added a quirk to force SOF to be used for ES8336 devices. It worked
> >>> for some, but not for others. Now we have quite a few ES8336-based
> >>> platforms that are broken with zero support from the vendor, with
> >>> obscure I2C/GPIO/clk issues.
> >>> Are we going to tag each one of them and say 'not supported, use HDMI only'?
> >>> That's pushing a bit the notion of quirk...It would generate an endless
> >>> stream of patches. The alternative is to do nothing and ask that those
> >>> platforms revert to HDMI audio only with a kernel parameter. That latter
> >>> alternative has my vote.
> >>> 
> >> 
> >> Given that this apparently does not work for many ES8336 devices,
> >> would it make more sense to disable SOF support for those by default
> >> and _enable_ them with a kernel parameter ?
> > 
> > Some configurations work, so we would break them.
> > 
> 
> Yes, but for others it is a regression,

Is it?  The speaker should have never worked for them without SOF,
either.


Takashi

> so arguably the change to force-enable
> SOF caused a regression and should either be reverted or fixed such that all
> previously working configurations still work (even more so since fixing
> the problem one-by-one as affected systems are found is being rejected).
> 
> Thanks,
> Guenter
> 

Re: [PATCH] ALSA: hda: intel-dsp-config: Fix Azulle Access 4 quirk detection

[Guenter Roeck]

On 6/26/24 06:37, Takashi Iwai wrote:
> On Wed, 26 Jun 2024 15:09:34 +0200,
> Guenter Roeck wrote:
>>
>> On 6/26/24 00:04, Pierre-Louis Bossart wrote:
>>>
>>>
>>> On 6/25/24 23:37, Guenter Roeck wrote:
>>>> On Fri, Jun 21, 2024 at 10:35:31AM +0200, Pierre-Louis Bossart wrote:
>>>>>
>>>>>
>>>>> On 6/21/24 08:15, Amadeusz Sławiński wrote:
>>>>>> On 6/20/2024 9:27 PM, Allen Ballway wrote:
>>>>>>> I filed a bug and after sharing the requested information it looks
>>>>>>> like this device won't work on SOF without vendor support. Given this,
>>>>>>> would the original patch returning this device to using HDAudio be
>>>>>>> reasonable, or is there an preferred alternative to force this device
>>>>>>> into using HDAudio?
>>>>>>>
>>>>>>
>>>>>> And can you share link to the issue on mailing list, so someone reading
>>>>>> this thread in the future doesn't have to guess where it is? ;)
>>>>>
>>>>> https://github.com/thesofproject/linux/issues/4981
>>>>>
>>>>> I don't know what to do with this configuration.
>>>>> We added a quirk to force SOF to be used for ES8336 devices. It worked
>>>>> for some, but not for others. Now we have quite a few ES8336-based
>>>>> platforms that are broken with zero support from the vendor, with
>>>>> obscure I2C/GPIO/clk issues.
>>>>> Are we going to tag each one of them and say 'not supported, use HDMI only'?
>>>>> That's pushing a bit the notion of quirk...It would generate an endless
>>>>> stream of patches. The alternative is to do nothing and ask that those
>>>>> platforms revert to HDMI audio only with a kernel parameter. That latter
>>>>> alternative has my vote.
>>>>>
>>>>
>>>> Given that this apparently does not work for many ES8336 devices,
>>>> would it make more sense to disable SOF support for those by default
>>>> and _enable_ them with a kernel parameter ?
>>>
>>> Some configurations work, so we would break them.
>>>
>>
>> Yes, but for others it is a regression,
> 
> Is it?  The speaker should have never worked for them without SOF,
> either.
> 

Interesting comment, especially in the context of the reasons given for this patch
to be rejected.

Guenter