Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 27 Apr 2020 17:15:55 +0200
Message-ID: <s5ho8rdnems.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     "Deucher, Alexander" <Alexander.Deucher@amd.com>
Cc:     Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
        Takashi Iwai <tiwai@suse.com>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
        Lukas Wunner <lukas@wunner.de>,
        "Koenig, Christian" <Christian.Koenig@amd.com>,
        "Zhou, David(ChunMing)" <David1.Zhou@amd.com>
Subject: Re: [PATCH 0/1] Fiji GPU audio register timeout when in BACO state
In-Reply-To: <MN2PR12MB4488E4909C1488FB507E0BF5F7AF0@MN2PR12MB4488.namprd12.prod.outlook.com>
References: <PSXP216MB0438D2AF96CE0D4F83F48C4D80AE0@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM>
        <MN2PR12MB4488E4909C1488FB507E0BF5F7AF0@MN2PR12MB4488.namprd12.prod.outlook.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 27 Apr 2020 16:22:21 +0200,
Deucher, Alexander wrote:
> 
> [AMD Public Use]
> 
> > -----Original Message-----
> > From: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
> > Sent: Sunday, April 26, 2020 12:02 PM
> > To: linux-kernel@vger.kernel.org
> > Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Koenig, Christian
> > <Christian.Koenig@amd.com>; Zhou, David(ChunMing)
> > <David1.Zhou@amd.com>; Nicholas Johnson <nicholas.johnson-
> > opensource@outlook.com.au>
> > Subject: [PATCH 0/1] Fiji GPU audio register timeout when in BACO state
> > 
> > Hi all,
> > 
> > Since Linux v5.7-rc1 / commit 4fdda2e66de0 ("drm/amdgpu/runpm: enable
> > runpm on baco capable VI+ asics"), my AMD R9 Nano has been using runpm /
> > BACO. You can tell visually when it sleeps, because the fan on the graphics
> > card is switched off to save power. It did not spin down the fan in v5.6.x.
> > 
> > This is great (I love it), except that when it is sleeping, the PCIe audio function
> > of the GPU has issues if anything tries to access it. You get dmesg errors such
> > as these:
> > 
> > snd_hda_intel 0000:08:00.1: spurious response 0x0:0x0, last cmd=0x170500
> > snd_hda_intel 0000:08:00.1: azx_get_response timeout, switching to polling
> > mode: last cmd=0x001f0500 snd_hda_intel 0000:08:00.1: No response from
> > codec, disabling MSI: last cmd=0x001f0500 snd_hda_intel 0000:08:00.1: No
> > response from codec, resetting bus: last cmd=0x001f0500
> > snd_hda_codec_hdmi hdaudioC1D0: Unable to sync register 0x2f0d00. -11
> > 
> > The above is with the Fiji XT GPU at 0000:08:00.0 in a Thunderbolt enclosure
> > (not that Thunderbolt should affect it, but I feel I should mention it just in
> > case). I dropped a lot of duplicate dmesg lines, as some of them repeated a
> > lot of times before the driver gave up.
> > 
> > I offer this patch to disable runpm for Fiji while a fix is found, if you decide
> > that is the best approach. Regardless, I will gladly test any patches you come
> > up with instead and confirm that the above issue has been fixed.
> > 
> > I cannot tell if any other GPUs are affected. The only other cards to which I
> > have access are a couple of AMD R9 280X (Tahiti XT), which use radeon driver
> > instead of amdgpu driver.
> 
> Adding a few more people.  Do you know what is accessing the audio?  The audio should have a dependency on the GPU device.  The GPU won't enter runtime pm until the audio has entered runtime pm and vice versa on resume. Please attach a copy of your dmesg output and lspci output.

Also, please retest with the fresh 5.7-rc3.  There was a known
regression regarding HD-audio PM in 5.7-rc1/rc2, and it's been fixed
there (commit 8d6762af302d).


thanks,

Takashi