Created attachment 282787 [details] alsa-info of E406MA We have an ASUS E406MA laptop equipped with Intel N5000 CPU. After system suspend & resume, the audio playback does not work anymore. The device for sound output is listed as a headphone device. Plugging in headphones no sound is audible neither. Here are the error messages after resume: [ 184.525681] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling mode: last cmd=0x20bf8100 [ 185.528682] snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last cmd=0x20bf8100 [ 186.532683] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x20bf8100 [ 186.736838] snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x2b8000. -5 [ 186.738742] snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x2b8000. -5 [ 186.767080] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5
Created attachment 282789 [details] dmesg includes before suspend and after resume
Created attachment 282797 [details] dmesg of 5.1.1 with reverted b5a236c175b0 We also found reverting the commit b5a236c175b0 "ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec" can solve this issue. No the error message "snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x2b8000. -5" in dmesg after resume.
The hda controller can't access the codec after s3. In theory the commit b5a236c175b0 will not introduce this issue, at least on other machines. Please do a test, with the kernel already reverting the commit, play some sound, while it is playing, let machine enter s3 and resume. After resuming back, check dmesg, is there the similar error log in the dmesg?
Also try to boot with no_console_suspend. Do I understand correctly that the first azx_get_response error is seen at the resume? If the suspend/resume during playing is broken as Hui guessed in comment 3, it's possibly because of some dependency of the hardware component.
And, judging from the error, it comes from the HDMI codec. Could you check whether masking the HDMI codec (probe_mask=0x01 option to snd_hda_intel module) makes the PM of the onboard audio working?
Thanks for the response from Hui Wang and Takashi Iwai! I also found latest Linux mainline kernel does not hit this issue right now. So I am doing bisect first. Hope I can find the commit and then it could be back ported.
Created attachment 282803 [details] dmesg with commit d31c85fc8642 and 905801fe7237 on Linux stable 5.1.3 The bisect in Linux mainline kernel goes to the commit 905801fe7237 "drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled". After cherry pick these two commits upon Linux stable kernel 5.1.3, this issue is gone. 905801fe7237 drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled d31c85fc8642 snd/hda, drm/i915: Track the display_power_status using a cookie No more error message like the following in dmesg after system resumes: snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x2b8000. -5 snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5 PS. The "original" Linux stable 5.1.3 also hits this issue.
Interesting. Is the latter mandatory? The commit was meant to catch any incorrect display power management from the audio, and not intended to fix any behavior change.
OK, I see that you've applied the commit d31c85fc8642 for applying 905801fe7237 cleanly. If the patch is modified, it should suffice to backport only 905801fe7237, I suppose.
(In reply to Takashi Iwai from comment #9) > OK, I see that you've applied the commit d31c85fc8642 for applying > 905801fe7237 cleanly. If the patch is modified, it should suffice to > backport only 905801fe7237, I suppose. I simply `git cherry-pick` these two commits. Could them be backported to 5.0 and 5.1. Because, I found Linux stable 5.0.6 also hits this issue.
After the cherry pick actions, this issue on * Linux 5.1.x can apply commit d31c85fc8642 and 905801fe7237 simply. * There are more commit dependencies for Linux 5.0.x.
We also need to backport 59f9e9cab3a1e6762fb707d0d829b982930f1349, otherwise the screen will be flickering when the CDCLK changes.
(In reply to Hui Wang from comment #12) > We also need to backport 59f9e9cab3a1e6762fb707d0d829b982930f1349, otherwise > the screen will be flickering when the CDCLK changes. Thanks for your feedback. Let's try to backport it.
Commit 59f9e9cab3a1 "drm/i915: Skip modeset for cdclk changes if possible" also needs commit 48d9f87ddd21 "drm/i915: Save the old CDCLK atomic state". Otherwise, system will have no frame buffer, due to lost /dev/dri/card0 on ASUS E406MA.
Yes, looks like need to backport 4 patches: 905801fe72377b4dc53c6e13eea1a91c6a4aa0c4 48d9f87ddd2108663fd866b254e05d422243cc56 2b21dfbeee725778daed2c3dd45a3fc808176feb 59f9e9cab3a1e6762fb707d0d829b982930f1349
According to the comment[1], the related commits are merged. This ticket can be closed. [1]: https://bugs.freedesktop.org/show_bug.cgi?id=110916#c5