| Message ID | 20190725080300.1913-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips" | expand |
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. thanks, Takashi > > Cc: Takashi Iwai <tiwai@suse.de> > --- > sound/pci/hda/hda_intel.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > index 324a4b20fba9..fdde80d95966 100644 > --- a/sound/pci/hda/hda_intel.c > +++ b/sound/pci/hda/hda_intel.c > @@ -313,10 +313,11 @@ enum { > > #define AZX_DCAPS_INTEL_SKYLAKE \ > (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME |\ > - AZX_DCAPS_SYNC_WRITE |\ > AZX_DCAPS_SEPARATE_STREAM_TAG | AZX_DCAPS_I915_COMPONENT) > > -#define AZX_DCAPS_INTEL_BROXTON AZX_DCAPS_INTEL_SKYLAKE > +#define AZX_DCAPS_INTEL_BROXTON \ > + (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME |\ > + AZX_DCAPS_SEPARATE_STREAM_TAG | AZX_DCAPS_I915_COMPONENT) > > /* quirks for ATI SB / AMD Hudson */ > #define AZX_DCAPS_PRESET_ATI_SB \ > -- > 2.22.0 >
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;
Quoting Takashi Iwai (2019-07-25 09:26:56) > 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? Due to the way patchwork works, this patch will now be tested instead of the revert. So watch this space. -Chris
Quoting Chris Wilson (2019-07-25 09:30:25) > Quoting Takashi Iwai (2019-07-25 09:26:56) > > 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? > > Due to the way patchwork works, this patch will now be tested instead of > the revert. So watch this space. Sadly, no change. Patchwork definitely lists this patch as being the one tested, but maybe send it separately just in case. -Chris
On Thu, 25 Jul 2019 12:21:11 +0200, Chris Wilson wrote: > > Quoting Chris Wilson (2019-07-25 09:30:25) > > Quoting Takashi Iwai (2019-07-25 09:26:56) > > > 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? > > > > Due to the way patchwork works, this patch will now be tested instead of > > the revert. So watch this space. > > Sadly, no change. Patchwork definitely lists this patch as being the one > tested, but maybe send it separately just in case. Hm, does the error indicate the same message ("last cmd=0x202f8100")? If yes, we might need another workaround. This is a special verb for Intel with some black magic to communicate with GPU. The tweak via this verb is needed for other platforms to assure the enablement of all pins and DP 1.2, but it might be incorrect for ICL. Can anyone at Intel check whether the verb (0x781/0xf81) is still valid for ICL? Anyways below is a patch to leave the verb access for ICL. Let's see... thanks, Takashi -- 8< -- From: Takashi Iwai <tiwai@suse.de> Subject: [PATCH] ALSA: hda/hdmi - Don't apply black magic to Icelake HDMI codecs The Intel-specific verb to enable all pins and DP 1.2 seems causing a problem on ICL by some reason. Skip applying the verb for ICL as a workaround. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- sound/pci/hda/patch_hdmi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 2096993eaf28..7e8236e5eac0 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2804,12 +2804,15 @@ static int intel_hsw_common_init(struct hda_codec *codec, hda_nid_t vendor_nid, spec->port_map = port_map; spec->port_num = port_num; - intel_haswell_enable_all_pins(codec, true); - intel_haswell_fixup_enable_dp12(codec); + if (!is_icelake(codec)) { + intel_haswell_enable_all_pins(codec, true); + intel_haswell_fixup_enable_dp12(codec); + } codec->display_power_control = 1; - codec->patch_ops.set_power_state = haswell_set_power_state; + if (!is_icelake(codec)) + codec->patch_ops.set_power_state = haswell_set_power_state; codec->depop_delay = 0; codec->auto_runtime_pm = 1;
Quoting Takashi Iwai (2019-07-25 11:44:08) > On Thu, 25 Jul 2019 12:21:11 +0200, > Chris Wilson wrote: > > > > Quoting Chris Wilson (2019-07-25 09:30:25) > > > Quoting Takashi Iwai (2019-07-25 09:26:56) > > > > 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? > > > > > > Due to the way patchwork works, this patch will now be tested instead of > > > the revert. So watch this space. > > > > Sadly, no change. Patchwork definitely lists this patch as being the one > > tested, but maybe send it separately just in case. > > Hm, does the error indicate the same message ("last cmd=0x202f8100")? https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13745/fi-icl-u2/igt@i915_module_load@reload.html <4> [383.858354] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x20170500 <4> [384.860261] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x20170500 <3> [556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 Looks different, indeed all the errors in BAT are last cmd=0x202f8100 -Chris
Quoting Takashi Iwai (2019-07-25 11:44:08) > On Thu, 25 Jul 2019 12:21:11 +0200, > Chris Wilson wrote: > > > > Quoting Chris Wilson (2019-07-25 09:30:25) > > > Quoting Takashi Iwai (2019-07-25 09:26:56) > > > > 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? > > > > > > Due to the way patchwork works, this patch will now be tested instead of > > > the revert. So watch this space. > > > > Sadly, no change. Patchwork definitely lists this patch as being the one > > tested, but maybe send it separately just in case. > > Hm, does the error indicate the same message ("last cmd=0x202f8100")? > If yes, we might need another workaround. This is a special verb for > Intel with some black magic to communicate with GPU. The tweak via > this verb is needed for other platforms to assure the enablement of > all pins and DP 1.2, but it might be incorrect for ICL. > > Can anyone at Intel check whether the verb (0x781/0xf81) is still > valid for ICL? > > Anyways below is a patch to leave the verb access for ICL. > Let's see... > > > thanks, > > Takashi > > -- 8< -- > From: Takashi Iwai <tiwai@suse.de> > Subject: [PATCH] ALSA: hda/hdmi - Don't apply black magic to Icelake HDMI > codecs > > The Intel-specific verb to enable all pins and DP 1.2 seems causing a > problem on ICL by some reason. Skip applying the verb for ICL as a > workaround. Hmm. Nothing with icl-hda managed to boot. Coincidence? > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > sound/pci/hda/patch_hdmi.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > index 2096993eaf28..7e8236e5eac0 100644 > --- a/sound/pci/hda/patch_hdmi.c > +++ b/sound/pci/hda/patch_hdmi.c > @@ -2804,12 +2804,15 @@ static int intel_hsw_common_init(struct hda_codec *codec, hda_nid_t vendor_nid, > spec->port_map = port_map; > spec->port_num = port_num; > > - intel_haswell_enable_all_pins(codec, true); > - intel_haswell_fixup_enable_dp12(codec); > + if (!is_icelake(codec)) { > + intel_haswell_enable_all_pins(codec, true); > + intel_haswell_fixup_enable_dp12(codec); > + } > > codec->display_power_control = 1; > > - codec->patch_ops.set_power_state = haswell_set_power_state; > + if (!is_icelake(codec)) > + codec->patch_ops.set_power_state = haswell_set_power_state; > codec->depop_delay = 0; > codec->auto_runtime_pm = 1; > > -- > 2.16.4 > >
On Thu, 25 Jul 2019 14:50:18 +0200, Chris Wilson wrote: > > Quoting Takashi Iwai (2019-07-25 11:44:08) > > On Thu, 25 Jul 2019 12:21:11 +0200, > > Chris Wilson wrote: > > > > > > Quoting Chris Wilson (2019-07-25 09:30:25) > > > > Quoting Takashi Iwai (2019-07-25 09:26:56) > > > > > 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? > > > > > > > > Due to the way patchwork works, this patch will now be tested instead of > > > > the revert. So watch this space. > > > > > > Sadly, no change. Patchwork definitely lists this patch as being the one > > > tested, but maybe send it separately just in case. > > > > Hm, does the error indicate the same message ("last cmd=0x202f8100")? > > If yes, we might need another workaround. This is a special verb for > > Intel with some black magic to communicate with GPU. The tweak via > > this verb is needed for other platforms to assure the enablement of > > all pins and DP 1.2, but it might be incorrect for ICL. > > > > Can anyone at Intel check whether the verb (0x781/0xf81) is still > > valid for ICL? > > > > Anyways below is a patch to leave the verb access for ICL. > > Let's see... > > > > > > thanks, > > > > Takashi > > > > -- 8< -- > > From: Takashi Iwai <tiwai@suse.de> > > Subject: [PATCH] ALSA: hda/hdmi - Don't apply black magic to Icelake HDMI > > codecs > > > > The Intel-specific verb to enable all pins and DP 1.2 seems causing a > > problem on ICL by some reason. Skip applying the verb for ICL as a > > workaround. > > Hmm. Nothing with icl-hda managed to boot. Coincidence? No idea, honestly speaking, but it's a bad sign. Let's scratch. Takashi > > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > > --- > > sound/pci/hda/patch_hdmi.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > > index 2096993eaf28..7e8236e5eac0 100644 > > --- a/sound/pci/hda/patch_hdmi.c > > +++ b/sound/pci/hda/patch_hdmi.c > > @@ -2804,12 +2804,15 @@ static int intel_hsw_common_init(struct hda_codec *codec, hda_nid_t vendor_nid, > > spec->port_map = port_map; > > spec->port_num = port_num; > > > > - intel_haswell_enable_all_pins(codec, true); > > - intel_haswell_fixup_enable_dp12(codec); > > + if (!is_icelake(codec)) { > > + intel_haswell_enable_all_pins(codec, true); > > + intel_haswell_fixup_enable_dp12(codec); > > + } > > > > codec->display_power_control = 1; > > > > - codec->patch_ops.set_power_state = haswell_set_power_state; > > + if (!is_icelake(codec)) > > + codec->patch_ops.set_power_state = haswell_set_power_state; > > codec->depop_delay = 0; > > codec->auto_runtime_pm = 1; > > > > -- > > 2.16.4 > > > > >
On Thu, 25 Jul 2019 12:49:12 +0200, Chris Wilson wrote: > > Quoting Takashi Iwai (2019-07-25 11:44:08) > > On Thu, 25 Jul 2019 12:21:11 +0200, > > Chris Wilson wrote: > > > > > > Quoting Chris Wilson (2019-07-25 09:30:25) > > > > Quoting Takashi Iwai (2019-07-25 09:26:56) > > > > > 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? > > > > > > > > Due to the way patchwork works, this patch will now be tested instead of > > > > the revert. So watch this space. > > > > > > Sadly, no change. Patchwork definitely lists this patch as being the one > > > tested, but maybe send it separately just in case. > > > > Hm, does the error indicate the same message ("last cmd=0x202f8100")? > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13745/fi-icl-u2/igt@i915_module_load@reload.html > <4> [383.858354] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x20170500 > <4> [384.860261] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x20170500 > <3> [556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 Looking at the logs around this, you can find: <7>[ 380.741747] [IGT] i915_module_load: executing <7>[ 380.745788] [IGT] i915_module_load: starting subtest reload <4>[ 383.858354] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x20170500 <4>[ 384.860261] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x20170500 <3>[ 556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 <3>[ 556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 <7>[ 556.636556] [drm:i915_audio_component_get_eld [i915]] Not valid for port B <7>[ 556.636681] [drm:i915_audio_component_get_eld [i915]] Not valid for port B <7>[ 556.636775] [drm:i915_audio_component_get_eld [i915]] Not valid for port B <7>[ 556.636865] [drm:i915_audio_component_get_eld [i915]] Not valid for port C <7>[ 556.636959] [drm:i915_audio_component_get_eld [i915]] Not valid for port C <7>[ 556.637042] [drm:i915_audio_component_get_eld [i915]] Not valid for port C <7>[ 556.637134] [drm:i915_audio_component_get_eld [i915]] Not valid for port D <7>[ 556.637312] [drm:i915_audio_component_get_eld [i915]] Not valid for port D <7>[ 556.637445] [drm:i915_audio_component_get_eld [i915]] Not valid for port E <7>[ 556.637557] [drm:i915_audio_component_get_eld [i915]] Not valid for port E <7>[ 556.637664] [drm:i915_audio_component_get_eld [i915]] Not valid for port E <7>[ 556.637751] [drm:i915_audio_component_get_eld [i915]] Not valid for port F <7>[ 556.637825] [drm:i915_audio_component_get_eld [i915]] Not valid for port F <7>[ 556.637900] [drm:i915_audio_component_get_eld [i915]] Not valid for port F <7>[ 556.679134] [IGT] i915_module_load: executing <7>[ 556.681585] [IGT] i915_module_load: starting subtest reload-no-display What does it actually do? First off, there is a big gap in the timestamps between 384 and 556. Then it shows "Unable to sync register", which indicates the regcache sync at resume failed, followed by the ELD checks showing all negative. So it's still all disconnected. Maybe it's trying to poke the graphics side before the gfx initialization completed? After this error, the HDMI audio codec seems completely screwed up, and the probe of codec#2 always failed. This loos pretty much like a timing related problem. Takashi
Quoting Takashi Iwai (2019-07-25 14:45:10) > On Thu, 25 Jul 2019 12:49:12 +0200, > Chris Wilson wrote: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13745/fi-icl-u2/igt@i915_module_load@reload.html > > <4> [383.858354] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x20170500 > > <4> [384.860261] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x20170500 > > <3> [556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 > > Looking at the logs around this, you can find: > > <7>[ 380.741747] [IGT] i915_module_load: executing > <7>[ 380.745788] [IGT] i915_module_load: starting subtest reload > <4>[ 383.858354] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x20170500 > <4>[ 384.860261] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x20170500 > <3>[ 556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 > <3>[ 556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 > <7>[ 556.636556] [drm:i915_audio_component_get_eld [i915]] Not valid for port B > <7>[ 556.636681] [drm:i915_audio_component_get_eld [i915]] Not valid for port B > <7>[ 556.636775] [drm:i915_audio_component_get_eld [i915]] Not valid for port B > <7>[ 556.636865] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > <7>[ 556.636959] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > <7>[ 556.637042] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > <7>[ 556.637134] [drm:i915_audio_component_get_eld [i915]] Not valid for port D > <7>[ 556.637312] [drm:i915_audio_component_get_eld [i915]] Not valid for port D > <7>[ 556.637445] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > <7>[ 556.637557] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > <7>[ 556.637664] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > <7>[ 556.637751] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > <7>[ 556.637825] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > <7>[ 556.637900] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > <7>[ 556.679134] [IGT] i915_module_load: executing > <7>[ 556.681585] [IGT] i915_module_load: starting subtest reload-no-display > > What does it actually do? First off, there is a big gap in the > timestamps between 384 and 556. Therein is where our current problem lies. Looking at the run just before this pair of commits, <6> [405.838716] [IGT] i915_module_load: executing <6> [405.841651] [IGT] i915_module_load: starting subtest reload <4> [408.976245] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x202f8100 <4> [409.980171] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x202f8100 <3> [410.985180] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x202f8100 <3> [411.227736] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -5 <7> [411.227849] [drm:i915_audio_component_get_eld [i915]] Not valid for port B <7> [411.227886] [drm:i915_audio_component_get_eld [i915]] Not valid for port B <7> [411.227917] [drm:i915_audio_component_get_eld [i915]] Not valid for port C <7> [411.227947] [drm:i915_audio_component_get_eld [i915]] Not valid for port C <7> [411.228004] [drm:i915_audio_component_get_eld [i915]] Not valid for port C <7> [411.228041] [drm:i915_audio_component_get_eld [i915]] Not valid for port D <7> [411.228077] [drm:i915_audio_component_get_eld [i915]] Not valid for port D <7> [411.228125] [drm:i915_audio_component_get_eld [i915]] Not valid for port D <7> [411.228160] [drm:i915_audio_component_get_eld [i915]] Not valid for port E <7> [411.228187] [drm:i915_audio_component_get_eld [i915]] Not valid for port E <7> [411.228214] [drm:i915_audio_component_get_eld [i915]] Not valid for port E <7> [411.228239] [drm:i915_audio_component_get_eld [i915]] Not valid for port F <7> [411.228265] [drm:i915_audio_component_get_eld [i915]] Not valid for port F <7> [411.228291] [drm:i915_audio_component_get_eld [i915]] Not valid for port F Same error, but no delay. There's no telltale to determine if this is during module unload or at the start of the next probe. > Then it shows "Unable to sync register", which indicates the regcache > sync at resume failed, followed by the ELD checks showing all > negative. So it's still all disconnected. Maybe it's trying to poke > the graphics side before the gfx initialization completed? That should also be accompanied by lots of bad mmio warnings, and would be very odd for: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6546/git-log-oneline.log 144ffb4c55b9 drm-tip: 2019y-07m-25d-05h-23m-02s UTC integration manifest 2756d9143aa5 ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips a30f1743e4f5 ALSA: line6: sizeof (byte) is always 1, use that fact. a6efe73f1e08 drm-tip: 2019y-07m-24d-10h-01m-04s UTC integration manifest > After this error, the HDMI audio codec seems completely screwed up, > and the probe of codec#2 always failed. > > This loos pretty much like a timing related problem. It got flagged as an issue because the reload test is suddenly hitting the timeout. -Chris
On Thu, 25 Jul 2019 15:57:10 +0200, Chris Wilson wrote: > > Quoting Takashi Iwai (2019-07-25 14:45:10) > > On Thu, 25 Jul 2019 12:49:12 +0200, > > Chris Wilson wrote: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13745/fi-icl-u2/igt@i915_module_load@reload.html > > > <4> [383.858354] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x20170500 > > > <4> [384.860261] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x20170500 > > > <3> [556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 > > > > Looking at the logs around this, you can find: > > > > <7>[ 380.741747] [IGT] i915_module_load: executing > > <7>[ 380.745788] [IGT] i915_module_load: starting subtest reload > > <4>[ 383.858354] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x20170500 > > <4>[ 384.860261] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x20170500 > > <3>[ 556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 > > <3>[ 556.636243] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -11 > > <7>[ 556.636556] [drm:i915_audio_component_get_eld [i915]] Not valid for port B > > <7>[ 556.636681] [drm:i915_audio_component_get_eld [i915]] Not valid for port B > > <7>[ 556.636775] [drm:i915_audio_component_get_eld [i915]] Not valid for port B > > <7>[ 556.636865] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > > <7>[ 556.636959] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > > <7>[ 556.637042] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > > <7>[ 556.637134] [drm:i915_audio_component_get_eld [i915]] Not valid for port D > > <7>[ 556.637312] [drm:i915_audio_component_get_eld [i915]] Not valid for port D > > <7>[ 556.637445] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > > <7>[ 556.637557] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > > <7>[ 556.637664] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > > <7>[ 556.637751] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > > <7>[ 556.637825] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > > <7>[ 556.637900] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > > <7>[ 556.679134] [IGT] i915_module_load: executing > > <7>[ 556.681585] [IGT] i915_module_load: starting subtest reload-no-display > > > > What does it actually do? First off, there is a big gap in the > > timestamps between 384 and 556. > > Therein is where our current problem lies. Looking at the run just before > this pair of commits, > > <6> [405.838716] [IGT] i915_module_load: executing > <6> [405.841651] [IGT] i915_module_load: starting subtest reload > <4> [408.976245] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x202f8100 > <4> [409.980171] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x202f8100 > <3> [410.985180] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x202f8100 > <3> [411.227736] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f8100. -5 > <7> [411.227849] [drm:i915_audio_component_get_eld [i915]] Not valid for port B > <7> [411.227886] [drm:i915_audio_component_get_eld [i915]] Not valid for port B > <7> [411.227917] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > <7> [411.227947] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > <7> [411.228004] [drm:i915_audio_component_get_eld [i915]] Not valid for port C > <7> [411.228041] [drm:i915_audio_component_get_eld [i915]] Not valid for port D > <7> [411.228077] [drm:i915_audio_component_get_eld [i915]] Not valid for port D > <7> [411.228125] [drm:i915_audio_component_get_eld [i915]] Not valid for port D > <7> [411.228160] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > <7> [411.228187] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > <7> [411.228214] [drm:i915_audio_component_get_eld [i915]] Not valid for port E > <7> [411.228239] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > <7> [411.228265] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > <7> [411.228291] [drm:i915_audio_component_get_eld [i915]] Not valid for port F > > Same error, but no delay. OK, that sheds some light. With the recent fix using the write-sync, each verb execution is synchronous and waits for the codec response. And judging from the log, at this state, the codec doesn't respond properly, so each verb execution gets some delay. This accumulated as a large delay in the end, now appearing as a significant timeout error. So, that's not the error triggered by the recent fix. It's been there, but just ignored, so far. > There's no telltale to determine if this is > during module unload or at the start of the next probe. This is an interesting question. And, the very puzzling fact seen in the log is that the codec tries to access 0x202f8100, which is verb 0xf81. This is exactly my last patch tried to avoid. Is this really the result *only* with my second patch? We may try a patch to disable two functions intel_haswell_enable_all_pins() and intel_haswell_fixup_enable_dp12() completely. If this still shows the same verb, something is really wrong in testing. Takashi -- 8< -- --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2567,14 +2567,15 @@ static void intel_haswell_fixup_connect_list(struct hda_codec *codec, snd_hda_override_conn_list(codec, nid, spec->num_cvts, spec->cvt_nids); } -#define INTEL_GET_VENDOR_VERB 0xf81 -#define INTEL_SET_VENDOR_VERB 0x781 +//#define INTEL_GET_VENDOR_VERB 0xf81 +//#define INTEL_SET_VENDOR_VERB 0x781 #define INTEL_EN_DP12 0x02 /* enable DP 1.2 features */ #define INTEL_EN_ALL_PIN_CVTS 0x01 /* enable 2nd & 3rd pins and convertors */ static void intel_haswell_enable_all_pins(struct hda_codec *codec, bool update_tree) { +#if 0 // XXX unsigned int vendor_param; struct hdmi_spec *spec = codec->spec; @@ -2591,10 +2592,12 @@ static void intel_haswell_enable_all_pins(struct hda_codec *codec, if (update_tree) snd_hda_codec_update_widgets(codec); +#endif // XXX } static void intel_haswell_fixup_enable_dp12(struct hda_codec *codec) { +#if 0 // XXX unsigned int vendor_param; struct hdmi_spec *spec = codec->spec; @@ -2608,6 +2611,7 @@ static void intel_haswell_fixup_enable_dp12(struct hda_codec *codec) snd_hdac_regmap_add_vendor_verb(&codec->core, INTEL_SET_VENDOR_VERB); snd_hda_codec_write_cache(codec, spec->vendor_nid, 0, INTEL_SET_VENDOR_VERB, vendor_param); +#endif // XXX } /* Haswell needs to re-issue the vendor-specific verbs before turning to D0.
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 324a4b20fba9..fdde80d95966 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -313,10 +313,11 @@ enum { #define AZX_DCAPS_INTEL_SKYLAKE \ (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME |\ - AZX_DCAPS_SYNC_WRITE |\ AZX_DCAPS_SEPARATE_STREAM_TAG | AZX_DCAPS_I915_COMPONENT) -#define AZX_DCAPS_INTEL_BROXTON AZX_DCAPS_INTEL_SKYLAKE +#define AZX_DCAPS_INTEL_BROXTON \ + (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME |\ + AZX_DCAPS_SEPARATE_STREAM_TAG | AZX_DCAPS_I915_COMPONENT) /* quirks for ATI SB / AMD Hudson */ #define AZX_DCAPS_PRESET_ATI_SB \
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.") Cc: Takashi Iwai <tiwai@suse.de> --- sound/pci/hda/hda_intel.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)