From patchwork Thu Nov 26 06:06:56 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Zhang, Xiong Y" X-Patchwork-Id: 7704491 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id EB2BCBF90C for ; Thu, 26 Nov 2015 06:07:04 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E2780207DD for ; Thu, 26 Nov 2015 06:07:03 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id B50EA207DB for ; Thu, 26 Nov 2015 06:07:02 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BDFE26EAD6; Wed, 25 Nov 2015 22:07:00 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 9F67B6EAD1 for ; Wed, 25 Nov 2015 22:06:59 -0800 (PST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 25 Nov 2015 22:07:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,346,1444719600"; d="scan'208";a="2491704" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga004.fm.intel.com with ESMTP; 25 Nov 2015 22:07:01 -0800 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 25 Nov 2015 22:06:58 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 25 Nov 2015 22:06:58 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.223]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.88]) with mapi id 14.03.0248.002; Thu, 26 Nov 2015 14:06:57 +0800 From: "Zhang, Xiong Y" To: Takashi Iwai Thread-Topic: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events Thread-Index: AQHQ4bN4pOZ0ZSv7WkeUUpP3w7YXop6tAxBg//+FuICAAI9XEP//hCmAgAG6W1A= Date: Thu, 26 Nov 2015 06:06:56 +0000 Message-ID: <8082FF9BCB2B054996454E47167FF4EC0B0F2834@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> <8082FF9BCB2B054996454E47167FF4EC0B0F1AE8@SHSMSX104.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "alsa-devel@alsa-project.org" , "intel-gfx@lists.freedesktop.org" , "Vetter, Daniel" , David Henningsson Subject: Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > On Wed, 25 Nov 2015 11:57:13 +0100, > Zhang, Xiong Y wrote: > > > > > 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 > > > > Strange, your patch couldn't get away the error message. > > OK, then it's not about the race *during* the hd-audio driver > resuming or such. I guess it's the other way round: the i915 driver > notifies it unnecessarily while it's getting off. The audio part of > HDMI controller relies on the i915 power state, so it's screwed up. > > Check with drm.debug option to see in which code path it's triggered. > If it's a call in i915 suspend, the call should be removed not to wake > up the audio part unnecessarily. [Zhang, Xiong Y] it is called in intel_audio_codec_disable() from i915 suspend. --- > This could remove the error message. Go through the audio driver, I found in_pm isn't zero only during call codec_suspend() and codec_resume(). atomic_inc_not_zero(&codec->in_pm) in snd_hdac_power_up_pm() isn't inc in_pm since in_pm is zero. Is this right ? thanks > BTW, I have a patchset to avoid the audio h/w wakeup by a new > component ops to get ELD and connection states. It was posted to > alsa-devel shortly ago just as a reference, but this should work well > in such a case, too. The test patches are found in test/hdmi-jack > branch of my sound git tree. > > > 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)