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=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 9FD6BC43331 for ; Mon, 30 Mar 2020 10:24:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 77D5920748 for ; Mon, 30 Mar 2020 10:24:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729396AbgC3KYI (ORCPT ); Mon, 30 Mar 2020 06:24:08 -0400 Received: from isilmar-4.linta.de ([136.243.71.142]:33906 "EHLO isilmar-4.linta.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729121AbgC3KYH (ORCPT ); Mon, 30 Mar 2020 06:24:07 -0400 X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES Received: from light.dominikbrodowski.net (brodo.linta [10.1.0.102]) by isilmar-4.linta.de (Postfix) with ESMTPSA id E96BA200107; Mon, 30 Mar 2020 10:24:05 +0000 (UTC) Received: by light.dominikbrodowski.net (Postfix, from userid 1000) id 7A4912048A; Mon, 30 Mar 2020 12:23:56 +0200 (CEST) Date: Mon, 30 Mar 2020 12:23:56 +0200 From: Dominik Brodowski To: Cezary Rojewski Cc: Mark Brown , kuninori.morimoto.gx@renesas.com, Pierre-Louis Bossart , Keyon Jie , alsa-devel@alsa-project.org, curtis@malainey.com, linux-kernel@vger.kernel.org, tiwai@suse.com, liam.r.girdwood@linux.intel.com Subject: Re: snd_hda_intel/sst-acpi sound breakage on suspend/resume since 5.6-rc1 Message-ID: <20200330102356.GA16588@light.dominikbrodowski.net> References: <20200318162029.GA3999@light.dominikbrodowski.net> <20200318192213.GA2987@light.dominikbrodowski.net> <20200318215218.GA2439@light.dominikbrodowski.net> <20200319130049.GA2244@light.dominikbrodowski.net> <20200319134139.GB3983@sirena.org.uk> <20200319165157.GA2254@light.dominikbrodowski.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200319165157.GA2254@light.dominikbrodowski.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 19, 2020 at 05:51:58PM +0100, Dominik Brodowski wrote: > On Thu, Mar 19, 2020 at 04:48:03PM +0100, Cezary Rojewski wrote: > > On 2020-03-19 14:41, Mark Brown wrote: > > > On Thu, Mar 19, 2020 at 02:00:49PM +0100, Dominik Brodowski wrote: > > > > > > > Have some good news now, namely that a bisect is complete: That pointed to > > > > 1272063a7ee4 ("ASoC: soc-core: care .ignore_suspend for Component suspend"); > > > > therefore I've added Kuninori Morimoto to this e-mail thread. > > > > > > If that's an issue it feels more like a driver bug in that if the driver > > > asked for ignore_suspend then it should expect not to have the suspend > > > callback called. > > > > > > > Requested for tests with following diff applied: > > > > diff --git a/sound/soc/intel/boards/broadwell.c > > b/sound/soc/intel/boards/broadwell.c > > index db7e1e87156d..6ed4c1b0a515 100644 > > --- a/sound/soc/intel/boards/broadwell.c > > +++ b/sound/soc/intel/boards/broadwell.c > > @@ -212,7 +212,6 @@ static struct snd_soc_dai_link broadwell_rt286_dais[] = > > { > > .init = broadwell_rt286_codec_init, > > .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | > > SND_SOC_DAIFMT_CBS_CFS, > > - .ignore_suspend = 1, > > .ignore_pmdown_time = 1, > > .be_hw_params_fixup = broadwell_ssp0_fixup, > > .ops = &broadwell_rt286_ops, > > That patch fixes the issue(s). I didn't even need to revert 64df6afa0dab > ("ASoC: Intel: broadwell: change cpu_dai and platform components for SOF") > on top of that. But you can assess better whether that patch needs care for > other reasons; for me, this one-liner you have suggested is perfect. Seems this patch didn't make it into v5.6 (and neither did the other ones you sent relating to the "dummy" components). Can these patches therefore be marked for stable, please? Thanks, Dominik 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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 AC23AC43331 for ; Mon, 30 Mar 2020 10:25:04 +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 37E9620733 for ; Mon, 30 Mar 2020 10:25:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="jZSt2pfa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37E9620733 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dominikbrodowski.net 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 82BF615F9; Mon, 30 Mar 2020 12:24:12 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 82BF615F9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1585563902; bh=rjezb/Ac1wX1IuJrq4uW/MBmAZ41KeZ8NrlVGNZBL0o=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=jZSt2pfaV2Us9A0aPsFOp6qKhX9390QpHFImdNXs6QP+6X5r9jU76JRHu/xQISe// CfYRQ3vxFyCaE8YdasI1u4Kx1F99ysLh+vZPtKFjFzBJccN33arhJyp6qvyyYcRXDG 25b0EVwa4hJebUX76yulubHH1DSHlDpiHyc6mYzE= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id F3D0FF80145; Mon, 30 Mar 2020 12:24:11 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id CB6C3F80148; Mon, 30 Mar 2020 12:24:09 +0200 (CEST) Received: from isilmar-4.linta.de (isilmar-4.linta.de [136.243.71.142]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 8066EF8010C for ; Mon, 30 Mar 2020 12:24:06 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8066EF8010C X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES Received: from light.dominikbrodowski.net (brodo.linta [10.1.0.102]) by isilmar-4.linta.de (Postfix) with ESMTPSA id E96BA200107; Mon, 30 Mar 2020 10:24:05 +0000 (UTC) Received: by light.dominikbrodowski.net (Postfix, from userid 1000) id 7A4912048A; Mon, 30 Mar 2020 12:23:56 +0200 (CEST) Date: Mon, 30 Mar 2020 12:23:56 +0200 From: Dominik Brodowski To: Cezary Rojewski Subject: Re: snd_hda_intel/sst-acpi sound breakage on suspend/resume since 5.6-rc1 Message-ID: <20200330102356.GA16588@light.dominikbrodowski.net> References: <20200318162029.GA3999@light.dominikbrodowski.net> <20200318192213.GA2987@light.dominikbrodowski.net> <20200318215218.GA2439@light.dominikbrodowski.net> <20200319130049.GA2244@light.dominikbrodowski.net> <20200319134139.GB3983@sirena.org.uk> <20200319165157.GA2254@light.dominikbrodowski.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200319165157.GA2254@light.dominikbrodowski.net> Cc: alsa-devel@alsa-project.org, kuninori.morimoto.gx@renesas.com, curtis@malainey.com, tiwai@suse.com, Keyon Jie , Pierre-Louis Bossart , linux-kernel@vger.kernel.org, liam.r.girdwood@linux.intel.com, Mark Brown 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 Thu, Mar 19, 2020 at 05:51:58PM +0100, Dominik Brodowski wrote: > On Thu, Mar 19, 2020 at 04:48:03PM +0100, Cezary Rojewski wrote: > > On 2020-03-19 14:41, Mark Brown wrote: > > > On Thu, Mar 19, 2020 at 02:00:49PM +0100, Dominik Brodowski wrote: > > > > > > > Have some good news now, namely that a bisect is complete: That pointed to > > > > 1272063a7ee4 ("ASoC: soc-core: care .ignore_suspend for Component suspend"); > > > > therefore I've added Kuninori Morimoto to this e-mail thread. > > > > > > If that's an issue it feels more like a driver bug in that if the driver > > > asked for ignore_suspend then it should expect not to have the suspend > > > callback called. > > > > > > > Requested for tests with following diff applied: > > > > diff --git a/sound/soc/intel/boards/broadwell.c > > b/sound/soc/intel/boards/broadwell.c > > index db7e1e87156d..6ed4c1b0a515 100644 > > --- a/sound/soc/intel/boards/broadwell.c > > +++ b/sound/soc/intel/boards/broadwell.c > > @@ -212,7 +212,6 @@ static struct snd_soc_dai_link broadwell_rt286_dais[] = > > { > > .init = broadwell_rt286_codec_init, > > .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | > > SND_SOC_DAIFMT_CBS_CFS, > > - .ignore_suspend = 1, > > .ignore_pmdown_time = 1, > > .be_hw_params_fixup = broadwell_ssp0_fixup, > > .ops = &broadwell_rt286_ops, > > That patch fixes the issue(s). I didn't even need to revert 64df6afa0dab > ("ASoC: Intel: broadwell: change cpu_dai and platform components for SOF") > on top of that. But you can assess better whether that patch needs care for > other reasons; for me, this one-liner you have suggested is perfect. Seems this patch didn't make it into v5.6 (and neither did the other ones you sent relating to the "dummy" components). Can these patches therefore be marked for stable, please? Thanks, Dominik