[alsa-devel] [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Wed, 25 Nov 2015 11:57:13 +0100,
Zhang, Xiong Y wrote:
> 
> > On Wed, 25 Nov 2015 10:56:51 +0100,
> > Zhang, Xiong Y wrote:
> > >
> > > Recently I always see the following error message during S4 or S3 resume
> > with drm-intel-nightly.
> > > [   97.778063] PM: Syncing filesystems ... done.
> > > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> > done.
> > > [   97.804297] PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
> > > [   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
> > > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff]
> > > [   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
> > > [   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
> > > [   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
> > > [   97.804387] PM: Marking nosave pages: [mem 0x88000000-0xffffffff]
> > > [   97.806363] PM: Basic memory bitmaps created
> > > [   97.806409] PM: Preallocating image memory... done (allocated 321557
> > pages)
> > > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> > MB/s)
> > > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
> > done.
> > > [   98.151998] Suspending console(s) (use no_console_suspend to debug)
> > > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2:
> > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > > [   99.178150] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178155] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0,
> > force 128
> > > [  101.189709] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> > switching to polling mode: last cmd=0x206f2f00
> > > [  102.195492] snd_hda_intel 0000:00:1f.3: No response from codec,
> > disabling MSI: last cmd=0x206f2f00
> > > [  103.201275] snd_hda_intel 0000:00:1f.3: azx_get_response timeout,
> > switching to single_cmd mode: last cmd=0x206f2f00
> > > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> > >
> > > The bisect result points to this commit.
> > > I checked this patch and had one question: if i915 driver wake up ahead of
> > snd_hda_intel driver during resume,  i915 driver will call audio driver's
> > hdmi_present_sense() function through this patch, but the audio interrupt is
> > disabled at this moment, how could hdmi_present_sense() get the response
> > from codec ?
> > 
> > Yeah, a bad thing happens there.  The fix should be simple like below,
> > though.  Basically the pins are checked in the resume callback in
> > anyway, so there is no need to handle the notification during PM.
> > 
> > Could you check whether it works?
> > 
> > 
> > thanks,
> > 
> > Takashi
> 
> Strange, your patch couldn't get away the error message.

OK, then it's not about the race *during* the hd-audio driver
resuming or such.  I guess it's the other way round: the i915 driver
notifies it unnecessarily while it's getting off.  The audio part of
HDMI controller relies on the i915 power state, so it's screwed up.

Check with drm.debug option to see in which code path it's triggered.
If it's a call in i915 suspend, the call should be removed not to wake
up the audio part unnecessarily.

BTW, I have a patchset to avoid the audio h/w wakeup by a new
component ops to get ELD and connection states.  It was posted to
alsa-devel shortly ago just as a reference, but this should work well
in such a case, too.  The test patches are found in test/hdmi-jack
branch of my sound git tree.


Takashi