From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34441C83000 for ; Wed, 29 Apr 2020 16:06:09 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B62F32073E for ; Wed, 29 Apr 2020 16:06:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="Q35murP+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B62F32073E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 09E9E1671; Wed, 29 Apr 2020 18:05:17 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 09E9E1671 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1588176367; bh=T4HSkmZQdeQ7HldKRRdISFUaWZkug/k0WHsFG5xzIoM=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Q35murP+r079H52m5mKQfKKh9CZFqM4MxO07qtMr3jUmNvEaY1pCQk/ME24Sl65NR 8IJuxAxM0f/vmz24sBXd+i+cZXBFZlaR+QF3FEv5TLOukM+YoXoC40af0qvQTTU1zU 1dL46Nc422o5Jujs9hqmsPVt2kndH4SJwtcifJwE= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 60AF2F80217; Wed, 29 Apr 2020 18:05:16 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 42183F8022B; Wed, 29 Apr 2020 18:05:12 +0200 (CEST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id A038FF80109 for ; Wed, 29 Apr 2020 18:05:05 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz A038FF80109 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6C07DAB91; Wed, 29 Apr 2020 16:05:04 +0000 (UTC) Date: Wed, 29 Apr 2020 18:05:04 +0200 Message-ID: From: Takashi Iwai To: Alex Deucher Subject: Re: [PATCH 0/1] Fiji GPU audio register timeout when in BACO state In-Reply-To: References: 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 Cc: "Zhou, David\(ChunMing\)" , "alsa-devel@alsa-project.org" , Nicholas Johnson , "linux-kernel@vger.kernel.org" , "amd-gfx@lists.freedesktop.org" , Takashi Iwai , Lukas Wunner , "Deucher, Alexander" , "Koenig, Christian" X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, 29 Apr 2020 17:47:47 +0200, Alex Deucher wrote: > > On Wed, Apr 29, 2020 at 11:27 AM Nicholas Johnson > wrote: > > > > On Wed, Apr 29, 2020 at 09:37:41AM +0200, Takashi Iwai wrote: > > > On Tue, 28 Apr 2020 16:48:45 +0200, > > > Nicholas Johnson wrote: > > > > > > > > > > > > > > > > > > > > FWIW, I have a fiji board in a desktop system and it worked fine when > > > > > > > > this code was enabled. > > > > > > > > > > > > > > Is the new DC code used for Fiji boards? IIRC, the audio component > > > > > > > binding from amdgpu is enabled only for DC, and without the audio > > > > > > > component binding the runtime PM won't be linked up, hence you can't > > > > > > > power up GPU from the audio side access automatically. > > > > > > > > > > > > > > > > > > > Yes, DC is enabled by default for all cards with runtime pm enabled. > > > > > > > > > > OK, thanks, I found that amdgpu got bound via component in the dmesg > > > > > output, too: > > > > > > > > > > [ 21.294927] snd_hda_intel 0000:08:00.1: bound 0000:08:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu]) > > > > > > > > > > This is the place soon after amdgpu driver gets initialized. > > > > > Then we see later another initialization phase: > > > > > > > > > > [ 26.904127] rfkill: input handler enabled > > > > > [ 37.264152] [drm] PCIE GART of 1024M enabled (table at 0x000000F400000000). > > > > > > > > > > here shows 10 seconds between them. Then, it complained something: > > > > > > > > > > > > > > > [ 37.363287] [drm] UVD initialized successfully. > > > > > [ 37.473340] [drm] VCE initialized successfully. > > > > > [ 37.477942] amdgpu 0000:08:00.0: [drm] Cannot find any crtc or sizes > > > > > > > > The above would be me hitting WindowsKey+P to change screens, but with > > > > no DisplayPort attached to Fiji, hence it unable to find crtc. > > > > > > > > > > > > > > ... and go further, and hitting HD-audio error: > > > > > > > > > That would be me having attached the DisplayPort and done WindowsKey+P > > > > again. > > > > > > > > > [ 38.936624] [drm] fb mappable at 0x4B0696000 > > > > > [ 38.936626] [drm] vram apper at 0x4B0000000 > > > > > [ 38.936626] [drm] size 33177600 > > > > > [ 38.936627] [drm] fb depth is 24 > > > > > [ 38.936627] [drm] pitch is 15360 > > > > > [ 38.936673] amdgpu 0000:08:00.0: fb1: amdgpudrmfb frame buffer device > > > > > [ 40.092223] snd_hda_intel 0000:08:00.1: azx_get_response timeout, switching to polling mode: last cmd=0x00170500 > > > > > > > > > > After this point, HD-audio communication was screwed up. > > > > > > > > > > This lastcmd in the above message is AC_SET_POWER_STATE verb for the > > > > > root node to D0, so the very first command to power up the codec. > > > > > The rest commands are also about the power up of each node, so the > > > > > whole error indicate that the power up at runtime resume failed. > > > > > > > > > > So, this looks to me as if the device gets runtime-resumed at the bad > > > > > moment? > > > > It does. However, this is not going to be easy to pin down. > > > > > > > > I moved from Arch to Ubuntu, and it behaves differently. I cannot > > > > trigger the bug in Ubuntu. Plus, it puts the GPUs asleep, even if > > > > attached at boot, unlike Arch. I will continue to try to trigger it. But > > > > even if this is a problem with the Linux distribution, it should not be > > > > able to trigger a kernel mode bug, so we should persist with finding it. > > > > > > Sure, that's a bug to be fixed. > > > > > > This made me thinking what happens if we load the HD-audio driver very > > > late. Could you try to blacklist snd-hda-intel module, then load it > > > manually after plugging the DP monitor and activating it? > > Attached dmesg-blacklist-* > > > > It is interesting. If I enable the monitor with the module unloaded, and > > then load the module, I cannot trigger the bug, even if disabling the > > monitor, waiting for GPU to sleep, and then waking again. > > > > Even if I wake monitor up, put to sleep again, and then insmod when > > sleeping, it does not cause bug when waking again. > > > > Is there anything special about the first time the monitor is used? > > > > What do you mean by used? Do you mean plugged in to the GPU or used > in the GUI? It might be easier to debug this without a GUI involved. > Can you try this at runlevel 3 or something equivalent for your > distro? > > When the GPU is powered up, the driver gets an interrupt when a > display is hotplugged and generates an event and userspace > applications can listen for these events. When the GPU is powered > down, there's no interrupt. I think most GUIs poll GPUs periodically > to handle this case so they can detect a new display even when the GPU > is off. Maybe we are getting some sort of race here. GUI queries GPU > driver, causes GPU to wake up, checks attached displays, GPU driver > resets runtime pm timer. GPU goes back to sleep. The detection > updates the ELD data which causes the HDA driver to wake up. It > assumes the hw is on and tries to query it. In the meantime, the GPU > has already powered everything down again. Well, but the code path there is the runtime PM resume of the audio device and it means that GPU must have been runtime-resumed again beforehand via the device link. So, it should have worked from the beginning but in reality not -- that is, apparently some inconsistency is found in the initial attempt of the runtime resume... Takashi