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 6D1E8CD128A for ; Wed, 3 Apr 2024 12:51:51 +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 AD7082CEC; Wed, 3 Apr 2024 14:51:39 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz AD7082CEC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1712148709; bh=4umRmk03vF9fr1bGI0vLvaFyerPGebWSjguYoGPrI8c=; 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=W1nFh2i+oDENn9dC2irpYtQBIOCydGyZtYfOHF2X6+gtOlNmj6c0XYMQ4abnrNlaz j93LGhCNzVfKP1NFH8mszGCECNn+hxxmZjl7IDj8VT1+rTP+9AYxuFFdj+7rcKwwdR qu4tHwGPPo0NrAMX6KRcJ2X4AtCiEGWW7C7Ljt/Y= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 4A136F805FF; Wed, 3 Apr 2024 14:50:48 +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 DBDE5F80601; Wed, 3 Apr 2024 14:50:47 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 41E0AF8015B; Wed, 3 Apr 2024 14:50:39 +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 DDAF4F8015B for ; Wed, 3 Apr 2024 14:50:27 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz DDAF4F8015B 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=Sb2l3lgO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712148630; x=1743684630; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=4umRmk03vF9fr1bGI0vLvaFyerPGebWSjguYoGPrI8c=; b=Sb2l3lgO9V4CpUq6FcXfffxO+EQAThkOAT2bPVswNmSUdOPyvG0kpMjs U3FAKu5j/edUs//oA1bxr6iVHU4q/D9VhCYzIvg+/vI9rG1EeCnQ9196I io2wIXeRzDlsNePW1m/h8BHUfpxtL12rLMe6/fok3fQh0NZRmiuxfMHUu 6aUrd6JexpoRYUqLen0Os1Q98Ortaa2/j+zWbmAm/La0EL+Sv2yTBmiwB lHkrUW231JzYvZqIEyWOZ07HRwyY9MVNhLuaOzLiLKz8FfckYUyEzwUzp HBii8UuqeRaXtA/1Mn8W8NnsMois7Zi50t8BwCIOAeWjatMJTkI4sc5CY g==; X-CSE-ConnectionGUID: z1yiH9phQWuYrZhd+I7Aiw== X-CSE-MsgGUID: X0zu+wO5S3aqrAFHtzmkyw== X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="7539287" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="7539287" 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:24 -0700 X-CSE-ConnectionGUID: BYDsrZNkTaC/LT2slJN6iw== X-CSE-MsgGUID: /OB8Lz1iQYq2CjAHV31VPQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18343217" 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:22 -0700 Message-ID: <600cef67-ad90-4b67-8da7-2006339d430b@linux.intel.com> Date: Tue, 2 Apr 2024 09:02:26 -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> Content-Language: en-US From: Pierre-Louis Bossart In-Reply-To: <87zfuc7gya.wl-kuninori.morimoto.gx@renesas.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-ID-Hash: 3W3Q75W5P5GNELHUD52NJ6UIXGTTKHYN X-Message-ID-Hash: 3W3Q75W5P5GNELHUD52NJ6UIXGTTKHYN 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/1/24 19:21, Kuninori Morimoto wrote: > > Hi Pierre-Louis > > Thank you for your review > >> 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. > > I could understand so far. > >> 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. > > But sorry I could understand this. > > "There is one warning added if there are no settings for a dailink" > > By [01/16] patch ? I think no warning is added. Or do you mean by [15/16] > patch ? Yes I looked at the entire series, it's just too complicated to look with diff. > > "we've lost the detection of a mismatch between dailink and the > set of cpu/codec dais that are part of this dailink" > > Sorry I couldn't understand about this. > Which mismatch detection we lost ?? Concrete sample / code / image > is very helpful for me to well understanding. With the older code, if the dpcm_playback was set for the dailink but there isn't any dai connected to support playback, an error was thrown. With the new code, if playback_only is set but there isn't any dai connected, there is no error thrown, is there? The point is that these flags are sometimes set in the machine driver, sometimes set in the framework, and the open is which one has the priority.