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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 8B18CC433E6 for ; Mon, 18 Jan 2021 13:22:40 +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 025B8206F9 for ; Mon, 18 Jan 2021 13:22:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 025B8206F9 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 E3CB2181C; Mon, 18 Jan 2021 14:21:46 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz E3CB2181C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1610976157; bh=Rx8wbrhecoXDpGUNhQExt3T5bZoH0ruyPbGZV2HLqtc=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=FGoLSJpuRnPpbzVw2cU8lopFhtNQlrrr7QF2QFUEmFEbt81Cwh/DAOrh63mgR9Jpu xB8DjRo1WIL8/fObCUfcxZukTjvA+/B4pPr2j8VqH2AxEAjx+nnZpMm7ovVyDfTWnE rT7HsayQ2D8PEhqk7DENyAPMIr4AajqWHFcITpGM= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 6C7DCF80166; Mon, 18 Jan 2021 14:21:46 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id C6EEFF8016E; Mon, 18 Jan 2021 14:21:44 +0100 (CET) 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 85EE2F800C0 for ; Mon, 18 Jan 2021 14:21:37 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 85EE2F800C0 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 36D61ACBA; Mon, 18 Jan 2021 13:21:37 +0000 (UTC) Date: Mon, 18 Jan 2021 14:21:36 +0100 Message-ID: From: Takashi Iwai To: Kai-Heng Feng Subject: Re: [PATCH] ALSA: hda: Balance runtime/system PM if direct-complete is disabled In-Reply-To: <20210118130937.164650-1-kai.heng.feng@canonical.com> References: <20210118130937.164650-1-kai.heng.feng@canonical.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 Cc: "moderated list:SOUND" , Kai Vehmanen , Harsha Priya , open list , tiwai@suse.com, Pierre-Louis Bossart , Mark Brown , Ranjani Sridharan , "Kenneth R . Crudup" 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 Mon, 18 Jan 2021 14:09:36 +0100, Kai-Heng Feng wrote: > > HDA controller can't be runtime-suspended after commit 215a22ed31a1 > ("ALSA: hda: Refactor codjc PM to use direct-complete optimization"), > which enables direct-complete for HDA codec. > > The HDA codec driver didn't expect direct-complete will be disabled > after it returns a positive value from prepare() callback. However, > there are some places that PM core can disable direct-complete. For > instance, system hibernation or when codec has subordinates like LEDs. Hmm. This sounds rather like the approach using the direct-complete isn't well suited for the purpose? The increasing number of regression reports worries me. > So if a device is prepared for direct-complete but PM core still calls > codec's suspend or freeze callback, resume the device to keep PM > operations balanced. I find the ping-pong of the resume/suspend there a bit odd. It's no refcount management but it invokes the real resume there, which is involved with lots of operations. Can we rather skip the hda_codec_suspend() call instead (while changing dev->power.power_state)? thanks, Takashi > Reported-by: Kenneth R. Crudup > Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") > Signed-off-by: Kai-Heng Feng > --- > sound/pci/hda/hda_codec.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > index 687216e74526..0afbced979df 100644 > --- a/sound/pci/hda/hda_codec.c > +++ b/sound/pci/hda/hda_codec.c > @@ -2997,6 +2997,9 @@ static void hda_codec_pm_complete(struct device *dev) > > static int hda_codec_pm_suspend(struct device *dev) > { > + if (pm_runtime_status_suspended(dev)) > + pm_runtime_resume(dev); > + > dev->power.power_state = PMSG_SUSPEND; > return hda_codec_suspend(dev); > } > @@ -3009,6 +3012,9 @@ static int hda_codec_pm_resume(struct device *dev) > > static int hda_codec_pm_freeze(struct device *dev) > { > + if (pm_runtime_status_suspended(dev)) > + pm_runtime_resume(dev); > + > dev->power.power_state = PMSG_FREEZE; > return hda_codec_suspend(dev); > } > -- > 2.29.2 > 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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 819C1C433E0 for ; Mon, 18 Jan 2021 13:23:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 47ACC2073C for ; Mon, 18 Jan 2021 13:23:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390894AbhARNXU (ORCPT ); Mon, 18 Jan 2021 08:23:20 -0500 Received: from mx2.suse.de ([195.135.220.15]:50646 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392150AbhARNWU (ORCPT ); Mon, 18 Jan 2021 08:22:20 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 36D61ACBA; Mon, 18 Jan 2021 13:21:37 +0000 (UTC) Date: Mon, 18 Jan 2021 14:21:36 +0100 Message-ID: From: Takashi Iwai To: Kai-Heng Feng Cc: tiwai@suse.com, "Kenneth R . Crudup" , Jaroslav Kysela , Pierre-Louis Bossart , Kai Vehmanen , Ranjani Sridharan , Mark Brown , Harsha Priya , alsa-devel@alsa-project.org (moderated list:SOUND), linux-kernel@vger.kernel.org (open list) Subject: Re: [PATCH] ALSA: hda: Balance runtime/system PM if direct-complete is disabled In-Reply-To: <20210118130937.164650-1-kai.heng.feng@canonical.com> References: <20210118130937.164650-1-kai.heng.feng@canonical.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Jan 2021 14:09:36 +0100, Kai-Heng Feng wrote: > > HDA controller can't be runtime-suspended after commit 215a22ed31a1 > ("ALSA: hda: Refactor codjc PM to use direct-complete optimization"), > which enables direct-complete for HDA codec. > > The HDA codec driver didn't expect direct-complete will be disabled > after it returns a positive value from prepare() callback. However, > there are some places that PM core can disable direct-complete. For > instance, system hibernation or when codec has subordinates like LEDs. Hmm. This sounds rather like the approach using the direct-complete isn't well suited for the purpose? The increasing number of regression reports worries me. > So if a device is prepared for direct-complete but PM core still calls > codec's suspend or freeze callback, resume the device to keep PM > operations balanced. I find the ping-pong of the resume/suspend there a bit odd. It's no refcount management but it invokes the real resume there, which is involved with lots of operations. Can we rather skip the hda_codec_suspend() call instead (while changing dev->power.power_state)? thanks, Takashi > Reported-by: Kenneth R. Crudup > Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") > Signed-off-by: Kai-Heng Feng > --- > sound/pci/hda/hda_codec.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > index 687216e74526..0afbced979df 100644 > --- a/sound/pci/hda/hda_codec.c > +++ b/sound/pci/hda/hda_codec.c > @@ -2997,6 +2997,9 @@ static void hda_codec_pm_complete(struct device *dev) > > static int hda_codec_pm_suspend(struct device *dev) > { > + if (pm_runtime_status_suspended(dev)) > + pm_runtime_resume(dev); > + > dev->power.power_state = PMSG_SUSPEND; > return hda_codec_suspend(dev); > } > @@ -3009,6 +3012,9 @@ static int hda_codec_pm_resume(struct device *dev) > > static int hda_codec_pm_freeze(struct device *dev) > { > + if (pm_runtime_status_suspended(dev)) > + pm_runtime_resume(dev); > + > dev->power.power_state = PMSG_FREEZE; > return hda_codec_suspend(dev); > } > -- > 2.29.2 >