[Bug 104952] New: [regression] Loss of i915 (Apollo Lake/Broxton) HDMI audio after display sleep v4.14+

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=104952

            Bug ID: 104952
           Summary: [regression] Loss of i915 (Apollo Lake/Broxton) HDMI
                    audio after display sleep v4.14+
           Product: DRI
           Version: XOrg git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: simon501098c at gmail.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 137170
  --> https://bugs.freedesktop.org/attachment.cgi?id=137170&action=edit
Dmesg output from drm-tip (2e76a2952923eba64c4f9baf461613bc42ee997a) kernel
booted with drm.debug=0x1e log_buf_len=1M

Starting with kernel 4.14.0, when DPMS turns the screen off, there is about a
50% chance that HDMI audio will break. This can be fixed by shutting down Xorg,
removing and reloading module snd_hda_intel and then restarting Xorg.

When the loss occurs, the following appears in a non-debug demsg a few seconds
after the DPMS off command is issued.

snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling
mode: last cmd=0x208f8100
snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last
cmd=0x208f8100
snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to single_cmd
mode: last cmd=0x208f8100
snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5


Confirmed to happen in 4.14.0, 4.15.0 as well as the latest drm-tip (commit
2e76a2952923eba64c4f9baf461613bc42ee997a).


Using git bisect, it seems to have started with commit
e8a3a2a3d7f7a194e0f0ad92c5dd636f908e7601 "drm/i915/gen9+: Don't remove
secondary power well requests"

The previous commit 42d9366d41a992631abaa15f5a881ae1235a8203 does not exhibit
this issue.

I've booted the same HDD in a Haswell (i5-4570T) system and could not reproduce
the issue.

So far I only see this issue when running Xorg and Kodi (I don't have a regular
desktop on this system but can install one if requested for testing). I've
tried plain Xorg with no window manager, then starting either xterm or Google
Chrome and haven't managed to reproduce the issue in that situation.

Timing seems to have some effect; sleeping after 60 seconds (60 seconds from
Xorg starting, or 60 seconds from the last DPMS on command) never exhibited the
issue after several tries. 90 seconds or more seems to be needed.

In the attached dmesg output, the following was performed (Kodi & Xorg started
at boot, around T=8).

T=144
xset -display :0 dpms force off
This did not cause the issue.

T=174
xset -display :0 dpms force on
HDMI audio OK

T=294
xset -display :0 dpms force off
Here this issue appears, with the regular dmesg error (azx_get_response
timeout) appearing at T=297.

T=349
xset -display :0 dpms force on
HDMI audio no longer functional.


System details:

Asrock J4205-ITX (pentium J4205)
Onboard LSPCON converting DP 2.0 to HDMI output. HDMI connection to Denon AVR
X3100W

# uname -m
x86_64
# uname -r
4.15.0+

OS: Gentoo Linux with profile default/linux/amd64/17.0

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180205/a546f6dc/attachment.html>