[PATCH] ALSA: hda - Force polling mode on CFL for fixing codec communication

[PATCH] ALSA: hda - Force polling mode on CFL for fixing codec communication

[Takashi Iwai]

We've observed too long probe time with Coffee Lake machines, and the
likely cause is some communication problem between the HD-audio
controller and the codec chips.  While the controller expects an IRQ
wakeup for each codec response, it seems sometimes missing, and it
takes one second for the controller driver to time out and read the
response in the polling mode.

Although we aren't sure about the real culprit yet, in this patch, we
put a workaround by forcing the polling mode as default for CFL
machines; the polling mode itself isn't too heavy, and much better
than other workarounds initially suggested (e.g. disabling
power-save), at least.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199007
Fixes: e79b0006c45c ("ALSA: hda - Add Coffelake PCI ID")
Reported-and-tested-by: Hui Wang <hui.wang@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/hda_intel.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index d5017adf9feb..c507c69029e3 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -375,6 +375,7 @@ enum {
 					((pci)->device == 0x160c))
 
 #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
+#define IS_CFL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa348)
 
 static char *driver_short_names[] = {
 	[AZX_DRIVER_ICH] = "HDA Intel",
@@ -1744,6 +1745,10 @@ static int azx_create(struct snd_card *card, struct pci_dev *pci,
 	else
 		chip->bdl_pos_adj = bdl_pos_adj[dev];
 
+	/* Workaround for a communication error on CFL (bko#199007) */
+	if (IS_CFL(pci))
+		chip->polling_mode = 1;
+
 	err = azx_bus_init(chip, model[dev], &pci_hda_io_ops);
 	if (err < 0) {
 		kfree(hda);
-- 
2.16.2

Re: [PATCH] ALSA: hda - Force polling mode on CFL for fixing codec communication

[Ughreja, Rakesh A]

>-----Original Message-----
>From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-
>project.org] On Behalf Of Takashi Iwai
>Sent: Wednesday, March 21, 2018 2:45 PM
>To: alsa-devel@alsa-project.org
>Cc: Hui Wang <hui.wang@canonical.com>
>Subject: [alsa-devel] [PATCH] ALSA: hda - Force polling mode on CFL for fixing
>codec communication
>
>We've observed too long probe time with Coffee Lake machines, and the
>likely cause is some communication problem between the HD-audio
>controller and the codec chips.  While the controller expects an IRQ
>wakeup for each codec response, it seems sometimes missing, and it
>takes one second for the controller driver to time out and read the
>response in the polling mode.
>

I think I faced similar problem while doing the HDA ASoC work.

I don't have any way to reproduce and test this. Can we increase
the delay after the link is powered ON. The present delay is 100usec,
can we make it 521 uSec ? Possibly the codec is not ready after
the link is powered on and so it's not responding.

File: hda_intel.c

	/* 4. turn link up: set SPA to 1 and wait CPA to 1 */
	intel_ml_lctl_set_power(chip, 1);
	udelay(100); --> change this to 521.

Regards,
Rakesh

Re: [PATCH] ALSA: hda - Force polling mode on CFL for fixing codec communication

[Takashi Iwai]

On Wed, 21 Mar 2018 10:39:35 +0100,
Ughreja, Rakesh A wrote:
> 
> 
> 
> >-----Original Message-----
> >From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-
> >project.org] On Behalf Of Takashi Iwai
> >Sent: Wednesday, March 21, 2018 2:45 PM
> >To: alsa-devel@alsa-project.org
> >Cc: Hui Wang <hui.wang@canonical.com>
> >Subject: [alsa-devel] [PATCH] ALSA: hda - Force polling mode on CFL for fixing
> >codec communication
> >
> >We've observed too long probe time with Coffee Lake machines, and the
> >likely cause is some communication problem between the HD-audio
> >controller and the codec chips.  While the controller expects an IRQ
> >wakeup for each codec response, it seems sometimes missing, and it
> >takes one second for the controller driver to time out and read the
> >response in the polling mode.
> >
> 
> I think I faced similar problem while doing the HDA ASoC work.
> 
> I don't have any way to reproduce and test this. Can we increase
> the delay after the link is powered ON. The present delay is 100usec,
> can we make it 521 uSec ? Possibly the codec is not ready after
> the link is powered on and so it's not responding.

I'm afraid that this wouldn't help since the issue appears repeatedly
at later points.

But still it's worth to try.  Hui, could you investigate?


thanks,

Takashi

> 
> File: hda_intel.c
> 
> 	/* 4. turn link up: set SPA to 1 and wait CPA to 1 */
> 	intel_ml_lctl_set_power(chip, 1);
> 	udelay(100); --> change this to 521.
> 
> Regards,
> Rakesh
> 

Re: [PATCH] ALSA: hda - Force polling mode on CFL for fixing codec communication

[Hui Wang]

On 2018年03月21日 17:48, Takashi Iwai wrote:
> On Wed, 21 Mar 2018 10:39:35 +0100,
> Ughreja, Rakesh A wrote:
>>
>>
>>> -----Original Message-----
>>> From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-
>>> project.org] On Behalf Of Takashi Iwai
>>> Sent: Wednesday, March 21, 2018 2:45 PM
>>> To: alsa-devel@alsa-project.org
>>> Cc: Hui Wang <hui.wang@canonical.com>
>>> Subject: [alsa-devel] [PATCH] ALSA: hda - Force polling mode on CFL for fixing
>>> codec communication
>>>
>>> We've observed too long probe time with Coffee Lake machines, and the
>>> likely cause is some communication problem between the HD-audio
>>> controller and the codec chips.  While the controller expects an IRQ
>>> wakeup for each codec response, it seems sometimes missing, and it
>>> takes one second for the controller driver to time out and read the
>>> response in the polling mode.
>>>
>> I think I faced similar problem while doing the HDA ASoC work.
>>
>> I don't have any way to reproduce and test this. Can we increase
>> the delay after the link is powered ON. The present delay is 100usec,
>> can we make it 521 uSec ? Possibly the codec is not ready after
>> the link is powered on and so it's not responding.
> I'm afraid that this wouldn't help since the issue appears repeatedly
> at later points.
>
> But still it's worth to try.  Hui, could you investigate?

OK,  I will test it tomorrow.

Regards,
Hui.

>
>
> thanks,
>
> Takashi
>
>> File: hda_intel.c
>>
>> 	/* 4. turn link up: set SPA to 1 and wait CPA to 1 */
>> 	intel_ml_lctl_set_power(chip, 1);
>> 	udelay(100); --> change this to 521.
>>
>> Regards,
>> Rakesh
>>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] ALSA: hda - Force polling mode on CFL for fixing codec communication

[Hui Wang]

On 2018年03月21日 21:09, Hui Wang wrote:
> On 2018年03月21日 17:48, Takashi Iwai wrote:
>> On Wed, 21 Mar 2018 10:39:35 +0100,
>> Ughreja, Rakesh A wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: alsa-devel-bounces@alsa-project.org 
>>>> [mailto:alsa-devel-bounces@alsa-
>>>> project.org] On Behalf Of Takashi Iwai
>>>> Sent: Wednesday, March 21, 2018 2:45 PM
>>>> To: alsa-devel@alsa-project.org
>>>> Cc: Hui Wang <hui.wang@canonical.com>
>>>> Subject: [alsa-devel] [PATCH] ALSA: hda - Force polling mode on CFL 
>>>> for fixing
>>>> codec communication
>>>>
>>>> We've observed too long probe time with Coffee Lake machines, and the
>>>> likely cause is some communication problem between the HD-audio
>>>> controller and the codec chips.  While the controller expects an IRQ
>>>> wakeup for each codec response, it seems sometimes missing, and it
>>>> takes one second for the controller driver to time out and read the
>>>> response in the polling mode.
>>>>
>>> I think I faced similar problem while doing the HDA ASoC work.
>>>
>>> I don't have any way to reproduce and test this. Can we increase
>>> the delay after the link is powered ON. The present delay is 100usec,
>>> can we make it 521 uSec ? Possibly the codec is not ready after
>>> the link is powered on and so it's not responding.
>> I'm afraid that this wouldn't help since the issue appears repeatedly
>> at later points.
>>
>> But still it's worth to try.  Hui, could you investigate?
>
> OK,  I will test it tomorrow.
>
> Regards,
> Hui.
>
I disabled the polling_mode and changed udelay(100) to 
udelay(521)/mdelay(521),  the problem still can be reproduced.

Looks like only enabling polling_mode can fix this problem. extending 
delay after intel_ml_lctl_set_power(chip, 1); does not help fix this 
problem.


Regards,
Hui.

>>
>>
>> thanks,
>>
>> Takashi
>>
>>> File: hda_intel.c
>>>
>>>     /* 4. turn link up: set SPA to 1 and wait CPA to 1 */
>>>     intel_ml_lctl_set_power(chip, 1);
>>>     udelay(100); --> change this to 521.
>>>
>>> Regards,
>>> Rakesh
>>>
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] ALSA: hda - Force polling mode on CFL for fixing codec communication

[Takashi Iwai]

On Thu, 22 Mar 2018 08:19:51 +0100,
Hui Wang wrote:
> 
> On 2018年03月21日 21:09, Hui Wang wrote:
> > On 2018年03月21日 17:48, Takashi Iwai wrote:
> >> On Wed, 21 Mar 2018 10:39:35 +0100,
> >> Ughreja, Rakesh A wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: alsa-devel-bounces@alsa-project.org
> >>>> [mailto:alsa-devel-bounces@alsa-
> >>>> project.org] On Behalf Of Takashi Iwai
> >>>> Sent: Wednesday, March 21, 2018 2:45 PM
> >>>> To: alsa-devel@alsa-project.org
> >>>> Cc: Hui Wang <hui.wang@canonical.com>
> >>>> Subject: [alsa-devel] [PATCH] ALSA: hda - Force polling mode on
> >>>> CFL for fixing
> >>>> codec communication
> >>>>
> >>>> We've observed too long probe time with Coffee Lake machines, and the
> >>>> likely cause is some communication problem between the HD-audio
> >>>> controller and the codec chips.  While the controller expects an IRQ
> >>>> wakeup for each codec response, it seems sometimes missing, and it
> >>>> takes one second for the controller driver to time out and read the
> >>>> response in the polling mode.
> >>>>
> >>> I think I faced similar problem while doing the HDA ASoC work.
> >>>
> >>> I don't have any way to reproduce and test this. Can we increase
> >>> the delay after the link is powered ON. The present delay is 100usec,
> >>> can we make it 521 uSec ? Possibly the codec is not ready after
> >>> the link is powered on and so it's not responding.
> >> I'm afraid that this wouldn't help since the issue appears repeatedly
> >> at later points.
> >>
> >> But still it's worth to try.  Hui, could you investigate?
> >
> > OK,  I will test it tomorrow.
> >
> > Regards,
> > Hui.
> >
> I disabled the polling_mode and changed udelay(100) to
> udelay(521)/mdelay(521),  the problem still can be reproduced.
> 
> Looks like only enabling polling_mode can fix this problem. extending
> delay after intel_ml_lctl_set_power(chip, 1); does not help fix this
> problem.

Thanks, that's what I expected.  Will include the tentative fix with
polling mode in the next pull request.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel