Re: [PATCH] Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"

From: Takashi Iwai <tiwai@suse.de>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
Date: Thu, 25 Jul 2019 10:26:56 +0200	[thread overview]
Message-ID: <s5h5znqtt7z.wl-tiwai@suse.de> (raw)
In-Reply-To: <s5h8ssmttq0.wl-tiwai@suse.de>

On Thu, 25 Jul 2019 10:16:07 +0200,
Takashi Iwai wrote:
> 
> On Thu, 25 Jul 2019 10:03:00 +0200,
> Chris Wilson wrote:
> > 
> > Just a heads up that icl is consistently showing
> > 
> > <4> [315.478830] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x202f8100
> > <4> [316.482799] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x202f8100
> > <3> [508.412915] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11
> > 
> > following commits 2756d9143aa5 ("ALSA: hda - Fix intermittent CORB/RIRB
> > stall on Intel chips") and a30f1743e4f5 ("ALSA: line6: sizeof (byte) is
> > always 1, use that fact.")
> 
> The verb that stalls (0x202f8100) is a read verb (0xf81, Intel
> vendor-specific verb for HDMI), so it shouldn't matter whether with or
> without write sync, because it needs to read the response in anyway.
> 
> If that patch broke anything, it means that something else was already
> broken.  Oh well, that ICL crap...
> 
> Is it about the runtime PM, or S3 or S4?  The only case we need to
> re-issue this verb is only S4, I suppose, so we may skip that in most
> cases.

Now checking the code, and I believe the workaround applied there can
be skipped for non-Haswell chips.  Could you try the patch below in
addition?


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: hda/hdmi - Avoid Haswell-specific power workaround on
 recent chips

The HDMI codec driver applies a vendor-specific verb before turning on
the AFG power on Intel chips.  This was needed for Haswell by some
reason, but apparently this breaks occasionally on other recent Intel
chips.

For papering over the problem, apply the workaround only for Haswell
chips.  The verb 0x781/f81 is restored via regcache later in anyway.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/patch_hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 2096993eaf28..68ffe169cf52 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2809,7 +2809,8 @@ static int intel_hsw_common_init(struct hda_codec *codec, hda_nid_t vendor_nid,
 
 	codec->display_power_control = 1;
 
-	codec->patch_ops.set_power_state = haswell_set_power_state;
+	if (is_haswell(codec))
+		codec->patch_ops.set_power_state = haswell_set_power_state;
 	codec->depop_delay = 0;
 	codec->auto_runtime_pm = 1;
 
-- 
2.16.4


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
