Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp662431pxb; Thu, 30 Sep 2021 14:24:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBOtlGKXYwkZwFTZvngNenCKNUZ14QyP/evVbnMM74giICUIkSZdsFfL7/Jlish79utz83 X-Received: by 2002:a05:6a00:238e:b0:44b:ec1c:9484 with SMTP id f14-20020a056a00238e00b0044bec1c9484mr6426042pfc.5.1633037051872; Thu, 30 Sep 2021 14:24:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633037051; cv=none; d=google.com; s=arc-20160816; b=K7nHEzxaB3+h5SRV8ybx7KuyAiV1KE62ZBgpuU8su5uJ3B1nZxK3cUdBkRxbsUZMG4 U4hoVP3evdSXKgDHFW2C9keSkQXIoazAxuJdHid+wjlWLRXzrlIaiuqrIAW5NBZTMvoT kDy9t0HdJgkJLTjPXVduN4R++jn4RMV1x0q3c2G3+LdZWN70RYaK1oFhHpxwDVqjJ1N4 W1WvFadBYVXZTR3YnBD0DsBWsIV+D1tlJRn3FK4NetEwxBWB4aKv74o05snBYczrh1lx ks4BsiqXXEFKgiLkJDU2IL5y0jPc9EQl3RThqPixQLh7yInKNaMF/KNdjVw/DuvFlZpP NPNg== 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=NNXz+wlopUg8QliHfOAlu+jqGdR0jFx99dvI8QgdrMI=; b=EZXj553dBPh9Emy16eaUi4WlI7JV791Wccbe7vcm3G4hxGQ3fcTycA+LUYciG2seOD hUPecOSqduEy148GorgKLHTO1XLrrHfivBtBbZlnQu1TjFkF+yvn5d5RWLCKrEUVVnn7 sxqsnJekUS6A1W1EtjFCZE5vbP5fFIWRtmDF+QWTIRn/9wSiLXXS8g56aIE5io3s8yjX sUF6Ycjw8JkcjatRhIocuHg6puiG3RBuGf6Ndafk04N1lmrHvLlrQivCf92FfGoqrZRF Xe91Wu4w9Uv/tTRVRTn6ZR27BYojdy3OKxKdFZ4GDSBcIoj3XuW+Ay5CdBo55jrGRfhO nzEg== 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 d12si3355318pgg.456.2021.09.30.14.23.58; Thu, 30 Sep 2021 14:24:11 -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 S1345683AbhI3TEO (ORCPT + 99 others); Thu, 30 Sep 2021 15:04:14 -0400 Received: from mga14.intel.com ([192.55.52.115]:4234 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345619AbhI3TDK (ORCPT ); Thu, 30 Sep 2021 15:03:10 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10123"; a="224919968" X-IronPort-AV: E=Sophos;i="5.85,336,1624345200"; d="scan'208";a="224919968" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2021 12:01:03 -0700 X-IronPort-AV: E=Sophos;i="5.85,336,1624345200"; d="scan'208";a="521314581" Received: from lcalx-mobl1.amr.corp.intel.com (HELO [10.212.88.180]) ([10.212.88.180]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2021 12:01:01 -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, sharadg@nvidia.com, linux-tegra@vger.kernel.org, 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> <70422e52-89d2-d926-b3f9-be59780d464e@nvidia.com> From: Pierre-Louis Bossart Message-ID: <40f098c8-b9e3-8da6-849a-eb9a39fefdb0@linux.intel.com> Date: Thu, 30 Sep 2021 14:00:59 -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: <70422e52-89d2-d926-b3f9-be59780d464e@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 1. The original issue at my end was not just a configuration redundancy. > I realize now that with more stream addition following error print is seen. >    "ASoC: too many users playback at open 4" > >    This is because the max DPCM users is capped at 8. Increasing this > may help (need to see what number is better), but does not address the > redundancy problem. Going back to this DPCM_MAX_BE_USERS definition, it seems rather arbitrary and not so useful indeed. /* first time the dpcm is open ? */ if (be->dpcm[stream].users == DPCM_MAX_BE_USERS) { dev_err(be->dev, "ASoC: too many users %s at open %d\n", stream ? "capture" : "playback", be->dpcm[stream].state); continue; } The comment is no longer aligned with the code, wondering if this is a feature or a bug. There's no reason to arbitrarily restrict the number of users of a BE, or the check would need to use platform-specific information such as the number of inputs/outputs supported by a mixer/demux. Maybe Morimoto-san can comment since this was added in: 1db19c151819 ('ASoC: soc-pcm: fixup dpcm_be_dai_startup() user count') We're not done with soc-pcm.c cleanups :-)