[Intel-gfx] [PATCH] Revert "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"
Takashi Iwai
tiwai at suse.de
Thu Jul 25 14:54:22 UTC 2019
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.
More information about the Intel-gfx
mailing list