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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4F083CD128A for ; Wed, 3 Apr 2024 12:52:19 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 7A8F02CF8; Wed, 3 Apr 2024 14:52:07 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 7A8F02CF8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1712148737; bh=kMKCTwKn8cIKYzkCfS7drdn8LHov9ndMuinvA3lbcgw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=l7dq8AG0MJjW7+uiwbQx6R3pdqj7+9Eg7XRWaeAkKaOLNHPmSOHE3LeWeZSGf9ACm /Vlb3gR8t6Jl0FyoN6Ww43tnSS7paCeXztUT+1c1zNGpU3lSRt7nfVZDSjHGSpGnRz ypbhd3oP3zLNUASlC15jyYGiQU+Js8bOke5pX5Ao= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 88F3EF8064C; Wed, 3 Apr 2024 14:50:53 +0200 (CEST) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id AB758F8060E; Wed, 3 Apr 2024 14:50:52 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 57373F805CA; Wed, 3 Apr 2024 14:50:44 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 29FB0F8020D for ; Wed, 3 Apr 2024 14:50:28 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 29FB0F8020D Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=FvJNPFYJ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712148631; x=1743684631; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=kMKCTwKn8cIKYzkCfS7drdn8LHov9ndMuinvA3lbcgw=; b=FvJNPFYJyt5NF09iih9ivV/uyjfuz8x1XtE7tw65EDtD5iUElzyhVN7t zpTXkXSgrOPu2NOtL4Q2JdDFLNCDkjcKPvtW9FrpawmGU3Y951rz++akc XlBi6n6yGLRQHWczKH/o7q7wh8TcLx3QKtOxccn+Z0OzncK6xrw+jtkS5 pvw3ibd6xNfk4Fv80kiJLnT2CksY61drHf6BMNbzSsroxtpZnuX7mzJLJ CpAyEoRlIUbBeaeEHrmKAH2+NFwAIev++ZYTnBtIBWvHh//iEqzh9DErp R/i8I8UJo45FYA/j1OvJD8vz/dEmnyAy5xl0MZ8OE7eH79P8SRCcj5ELD A==; X-CSE-ConnectionGUID: T0LsHCntSDOBgZQGUlZSLA== X-CSE-MsgGUID: sKA3Jan/QtSM4ZgzHzXe4g== X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="7539311" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="7539311" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 05:50:26 -0700 X-CSE-ConnectionGUID: hVk+VsPMTNGqw+pBvOSqyw== X-CSE-MsgGUID: RwciptEsRAWsX8VxQF1m0Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18343230" Received: from makulkar-mobl1.amr.corp.intel.com (HELO [10.212.52.18]) ([10.212.52.18]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 05:50:24 -0700 Message-ID: <27d79c07-4ff9-48f4-9785-2643a8c5f4c5@linux.intel.com> Date: Tue, 2 Apr 2024 09:06:16 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/16] ASoC: soc-pcm.c: cleanup soc_get_playback_capture() To: Kuninori Morimoto Cc: =?UTF-8?Q?Amadeusz_S=C5=82awi=C5=84ski?= , Alper Nebi Yasak , AngeloGioacchino Del Regno , Banajit Goswami , Bard Liao , Brent Lu , Cezary Rojewski , Cristian Ciocaltea , Daniel Baluta , Hans de Goede , Jaroslav Kysela , Jerome Brunet , Kai Vehmanen , Kevin Hilman , Liam Girdwood , Linus Walleij , Mark Brown , Maso Huang , Matthias Brugger , Neil Armstrong , Peter Ujfalusi , Ranjani Sridharan , Sascha Hauer , Shawn Guo , Shengjiu Wang , Srinivas Kandagatla , Sylwester Nawrocki , Takashi Iwai , Trevor Wu , Vinod Koul , Xiubo Li , alsa-devel@alsa-project.org, imx@lists.linux.dev, linux-sound@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com References: <87zfuesz8y.wl-kuninori.morimoto.gx@renesas.com> <87y19xudor.wl-kuninori.morimoto.gx@renesas.com> <87zfuc7gya.wl-kuninori.morimoto.gx@renesas.com> <87ttkk9se3.wl-kuninori.morimoto.gx@renesas.com> Content-Language: en-US From: Pierre-Louis Bossart In-Reply-To: <87ttkk9se3.wl-kuninori.morimoto.gx@renesas.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-ID-Hash: GKC2H6NODSZTJUMPHXMQEYVETF54PGF7 X-Message-ID-Hash: GKC2H6NODSZTJUMPHXMQEYVETF54PGF7 X-MailFrom: pierre-louis.bossart@linux.intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 4/2/24 01:43, Kuninori Morimoto wrote: > > Hi Pierre-Louis, again > >>> The problem I have is with the following code (not shown with diff) >>> >>> if (dai_link->playback_only) >>> has_capture = 0; >>> >>> if (dai_link->capture_only) >>> has_playback = 0; >>> >>> So with this grand unification, all the loops above may make a decision >>> that could be overridden by these two branches. >>> >>> This was not the case before for DPCM, all the 'has_capture' and >>> 'has_playback' variables were used as a verification of the dai_link >>> settings with an error thrown e.g. if the dpcm_playback was set without >>> any DAIs supporting playback. > > Hmm... above 2 branches are used for DPCM too before. Not really, playback_only and capture_only were never set so those two branches were always false. > >>> Now the dailink settings are used unconditionally. There is one warning >>> added if there are no settings for a dailink, but we've lost the >>> detection of a mismatch between dailink and the set of cpu/codec dais >>> that are part of this dailink. > > Does this mean, for example you want to have warning/error by dpcm_playback > flag if you are thinking it can use playback , but FE or BE playback was > not valid ? Again we had a verification that if the dpcm_playback was set at the dailink level, it was actually supported by the dais. We seem to have lost this verification. We only have an error when there are no settings at all. > > If so, yes indeed this patch removes such flags. > But I wonder why you want to get it in case of DPCM only ? It's helpful to detect invalid configurations. And I see to reason why the removal of flags should change the functionality. > I can understand if all case want to have it. > > Then, I think we can check _only for this purpose too ? > > (A) if dai_link has playback_only -> it should have has_playback > (B) if dai_link has capture_only -> it should have has_capture > (C) if dai_link don't have both xxx_only -> it should have both has_xxx > > I think we already have (A)(B) check. We want to add (C) check ? > > If my understanding was correct, the things dpcm_xxx flag can do is also > can do by xxx_only flag. But dpcm_xxx flag is used only DPCM, but xxx_only > flag is used on all cases. I am only concerned about mismatches between dailinks and dai capabilities. The logic above is fine, but it's in the scope of the dailink only.