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

[Takashi Iwai]

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