From patchwork Wed Nov 25 10:07:53 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Takashi Iwai X-Patchwork-Id: 7696811 Return-Path: X-Original-To: patchwork-alsa-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E4AFD9F1D3 for ; Wed, 25 Nov 2015 10:08:15 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id EC37F208D1 for ; Wed, 25 Nov 2015 10:08:14 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.kernel.org (Postfix) with ESMTP id 8F4C9208BC for ; Wed, 25 Nov 2015 10:08:13 +0000 (UTC) Received: by alsa0.perex.cz (Postfix, from userid 1000) id E92EA261A03; Wed, 25 Nov 2015 11:08:11 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_DNS_FOR_FROM, RCVD_IN_DNSWL_LOW, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from alsa0.perex.cz (localhost [127.0.0.1]) by alsa0.perex.cz (Postfix) with ESMTP id 8478C26155B; Wed, 25 Nov 2015 11:08:04 +0100 (CET) X-Original-To: alsa-devel@alsa-project.org Delivered-To: alsa-devel@alsa-project.org Received: by alsa0.perex.cz (Postfix, from userid 1000) id EFF23261560; Wed, 25 Nov 2015 11:08:02 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id C560D261555 for ; Wed, 25 Nov 2015 11:07:55 +0100 (CET) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 258A5AB13; Wed, 25 Nov 2015 10:06:15 +0000 (UTC) Date: Wed, 25 Nov 2015 11:07:53 +0100 Message-ID: From: Takashi Iwai To: "Zhang, Xiong Y" In-Reply-To: <8082FF9BCB2B054996454E47167FF4EC0B0F19F8@SHSMSX104.ccr.corp.intel.com> References: <1440781350-12053-1-git-send-email-david.henningsson@canonical.com> <1440781350-12053-5-git-send-email-david.henningsson@canonical.com> <8082FF9BCB2B054996454E47167FF4EC0B0F19F8@SHSMSX104.ccr.corp.intel.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/24.5 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "Yang, Libin" , "alsa-devel@alsa-project.org" , "intel-gfx@lists.freedesktop.org" , "jani.nikula@linux.intel.com" , "Vetter, Daniel" , David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.14 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-bounces@alsa-project.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, 25 Nov 2015 10:56:51 +0100, Zhang, Xiong Y wrote: > > Recently I always see the following error message during S4 or S3 resume with drm-intel-nightly. > [ 97.778063] PM: Syncing filesystems ... done. > [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done. > [ 97.804297] PM: Marking nosave pages: [mem 0x00000000-0x00000fff] > [ 97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff] > [ 97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff] > [ 97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff] > [ 97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff] > [ 97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff] > [ 97.804387] PM: Marking nosave pages: [mem 0x88000000-0xffffffff] > [ 97.806363] PM: Basic memory bitmaps created > [ 97.806409] PM: Preallocating image memory... done (allocated 321557 pages) > [ 98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 MB/s) > [ 98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. > [ 98.151998] Suspending console(s) (use no_console_suspend to debug) > [ 98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1 > [ 99.178150] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178151] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178152] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178153] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178154] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178155] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x206f2e08 > [ 99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 128 > [ 101.189709] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x206f2f00 > [ 102.195492] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x206f2f00 > [ 103.201275] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x206f2f00 > [ 103.201396] azx_single_wait_for_response: 42 callbacks suppressed > > The bisect result points to this commit. > I checked this patch and had one question: if i915 driver wake up ahead of snd_hda_intel driver during resume, i915 driver will call audio driver's hdmi_present_sense() function through this patch, but the audio interrupt is disabled at this moment, how could hdmi_present_sense() get the response from codec ? Yeah, a bad thing happens there. The fix should be simple like below, though. Basically the pins are checked in the resume callback in anyway, so there is no need to handle the notification during PM. Could you check whether it works? thanks, Takashi diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index bdb6f226d006..b468fe0e6195 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port) struct hda_codec *codec = audio_ptr; int pin_nid = port + 0x04; - check_presence_and_report(codec, pin_nid); + /* don't call notifier during PM; will be checked in resume callback */ + if (!atomic_read(&codec->core.in_pm)) + check_presence_and_report(codec, pin_nid); } static int patch_generic_hdmi(struct hda_codec *codec)