Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp22603pxb; Tue, 28 Sep 2021 14:27:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+MEYu0Oso7OkMWaqd6O+ClzFxrGYxgujdrrgaWI2lk0fG2j9/fbbXAJJ2GqoHlR5pE+/U X-Received: by 2002:a17:902:c40e:b0:13d:c2c4:2203 with SMTP id k14-20020a170902c40e00b0013dc2c42203mr7161267plk.46.1632864468607; Tue, 28 Sep 2021 14:27:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632864468; cv=none; d=google.com; s=arc-20160816; b=yZL6k6nN4lM6gapwfAZqTDk0o8k4reuqIBjlxKPE3MB/WHC75TzlaTC+Pm4zq8g177 v2x0q88GQOuP6VMAWq81HjjZd8zs5dX8e/NFrweb76/1b22UACN+KqYpb4OkbMN+XGMW rv4f0AZK8zoujiPzn+xY+qCg+aGegEqI0R8eK3Urho+bZZoHc1C9YY37VGZc19hPdz8j YnK2Vz/kktvPa6NOujMyLhprD7YHsP954w49EAMpr4ZIthJoYxbDvrk52htDjRQ7MGER FRChOxTsxgQOmp7zgufyz8Gqj3ANiQGjZakbKWILtP9VXq/EHOzCr4lVL3UYOhAZOh71 DyGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=iOId4FgTK7gAQf8HJBu2Nt0ixKrfMIt4xRefzudXOxQ=; b=De0DJvmwb1pO1Wx8XtDG9tQKT5Tl0MuHwBRgE0Ftx+Jod8D76K+jq9JsFJLnyTgbau SSA5Mk8QsR0NWDzCmypPdH/diBfn2exzmvgOHMG1cX6VzDslwKYBrKMWExnaLude9k1N 8zJPDcLHh1WUqYehkSPF1Jgf/k46nZcCOt+V2wqfREuXr+WlSRy6fKJXIBNIGnELnErV bCegwaez57lnLMGecAmuMi2/StmUiYaif6xFCmOD0yE23QVZEKzvzS5OeppOK5SChIjm GZLzP17Ch4xfYxml89GpA/nqy3D2D472pljPKkKCbWhk9LbOhSuiPuaYopls/IzEI79V JPiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e7si416752pgi.36.2021.09.28.14.26.57; Tue, 28 Sep 2021 14:27:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242915AbhI1V11 (ORCPT + 99 others); Tue, 28 Sep 2021 17:27:27 -0400 Received: from mga03.intel.com ([134.134.136.65]:25179 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242846AbhI1V1Z (ORCPT ); Tue, 28 Sep 2021 17:27:25 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10121"; a="224877767" X-IronPort-AV: E=Sophos;i="5.85,330,1624345200"; d="scan'208";a="224877767" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2021 14:25:44 -0700 X-IronPort-AV: E=Sophos;i="5.85,330,1624345200"; d="scan'208";a="438223466" Received: from ppahwa-mobl1.amr.corp.intel.com (HELO [10.212.48.236]) ([10.212.48.236]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2021 14:25:43 -0700 Subject: Re: [PATCH 01/13] ASoC: soc-pcm: Don't reconnect an already active BE To: Sameer Pujar , broonie@kernel.org, lgirdwood@gmail.com, robh+dt@kernel.org, thierry.reding@gmail.com, jonathanh@nvidia.com, catalin.marinas@arm.com, will@kernel.org, perex@perex.cz, tiwai@suse.com, kuninori.morimoto.gx@renesas.com Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, sharadg@nvidia.com, linux-arm-kernel@lists.infradead.org References: <1630056839-6562-1-git-send-email-spujar@nvidia.com> <1630056839-6562-2-git-send-email-spujar@nvidia.com> From: Pierre-Louis Bossart Message-ID: Date: Tue, 28 Sep 2021 16:25:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <1630056839-6562-2-git-send-email-spujar@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/27/21 4:33 AM, Sameer Pujar wrote: > In some cases, multiple FE components have the same BE component in their > respective DPCM paths. One such example would be a mixer component, which > can receive two or more inputs and sends a mixed output. In such cases, > to avoid reconfiguration of already active DAI (mixer output DAI in this > case), check the BE stream state to filter out the redundancy. > > In summary, allow connection of BE if the respective current stream state > is either NEW or CLOSED. This patch breaks our SOF CI tests, ironically in all cases where we have a mixer with a 'Deep buffer' port! The tests with multiple streams all fail with this error: [ 124.366400] Port0 Deep Buffer: ASoC: no backend DAIs enabled for Port0 Deep Buffer [ 124.366406] Port0 Deep Buffer: ASoC: dpcm_fe_dai_prepare() failed (-22) Reverting this patch restore the mixer functionality. I see multiple problems with this patch: At a high-level, there's at least a race condition where this BE state is checked without any protection. That was already a problem that I highlighted in a recent RFC and still working on, when we have multiple FEs we can have START/STOP triggers happening concurrently and it's necessary to serialize these triggers when checking the state, and this patch increases the 'surface' for this race condition. But in addition we'd need to agree on what an 'active BE' is. Why can't we connect a second stream while the first one is already in HW_PARAMS or PAUSED or STOP? It's perfectly legal in ALSA/ASoC to have multiple HW_PARAMS calls, and when we reach STOP we have to do a prepare again. And more fundamentally, the ability to add a second FE on a 'active' BE in START state is a basic requirement for a mixer, e.g. to play a notification on one FE while listening to music on another. What needs to happen is only to make sure that the FE and BE are compatible in terms of HW_PARAMS and not sending a second TRIGGER_STOP, only checking the BE NEW or CLOSE state is way too restrictive. I will agree this sort of mixer use cases is not well supported in soc-pcm.c, but let's not make it worse than it was before this patch, shall we? I can send a revert with the explanations in the commit message if there is a consensus that this patch needs to be revisited. [1] https://github.com/thesofproject/linux/pull/3177 [2] https://sof-ci.01.org/linuxpr/PR3177/build6440/devicetest/ > Signed-off-by: Sameer Pujar > --- > sound/soc/soc-pcm.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c > index 48f71bb..e30cb5a 100644 > --- a/sound/soc/soc-pcm.c > +++ b/sound/soc/soc-pcm.c > @@ -1395,6 +1395,10 @@ static int dpcm_add_paths(struct snd_soc_pcm_runtime *fe, int stream, > if (!fe->dpcm[stream].runtime && !fe->fe_compr) > continue; > > + if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_NEW) && > + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_CLOSE)) > + continue; > + > /* newly connected FE and BE */ > err = dpcm_be_connect(fe, be, stream); > if (err < 0) { >