Hi Lukas, Our OEM report the issue also can be observed with v4.17rc7 of test platform, and I also backported these 7 patches to v4.15, have confirmed the issue. Now, I found the audio device will auto suspend even if the gpu is active, and if I plug in a HDMI device it also do not resume back. 1. Did you encounter similar issue before? 2. audio will auto suspend as default at beginning of boot, is it expect behaviour? Device links help us handle two things: 1. make the audio/gpu suspend/resume/poweroff processing in an orderly way with the DL_FLAG_STATELESS flag. 2. it can guarantee the audio can be accessed if gpu is poweroffed by setting the DL_FLAG_PM_RUNTIME flag. So, in my opinion, audio's suspend/resume should be processed with gpu suspend/resume. Thanks JimQu ________________________________________ å??件人: Lukas Wunner <lukas at wunner.de> å??é??æ?¶é?´: 2018å¹´6æ??29æ?¥ 19:11 æ?¶ä»¶äºº: Qu, Jim æ??é??: alsa-devel at alsa-project.org; dri-devel at lists.freedesktop.org; Deucher, Alexander; amd-gfx at lists.freedesktop.org 主é¢?: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id On Fri, Jun 29, 2018 at 10:40:50AM +0000, Qu, Jim wrote: > > That is no longer the case since v4.17. The HDA controller now runtime > > suspends autonomously, see commit 07f4f97d7b4b ("vga_switcheroo: Use > > device link for HDA controller"). > > > > Your patch appears to be geared towards an older kernel version. > > Please retest on the laptop in question with a v4.17+ kernel. > > indeed? I used 4.13 on the platform. let me have a try with the patch > you mentioned The commit can't be cherry-picked by itself onto v4.13, it was part of a larger series. It's best to use a stock v4.17 kernel. Note, a fix went into Linus' tree yesterday, commit 57cb54e53bdd ("ALSA: hda - Force to link down at runtime suspend on ATI/AMD HDMI"). Not sure if it's needed on your machine. Thanks, Lukas