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=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 96385C47087 for ; Wed, 26 May 2021 02:47:19 +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 CEE646142D for ; Wed, 26 May 2021 02:47:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CEE646142D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=renesas.com 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 9D5B81748; Wed, 26 May 2021 04:46:25 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 9D5B81748 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1621997235; bh=Av+xPGndkQ2trmh/xk3liZhZbqz9ESY72MgXDsP+YV8=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ctB/NsGSQacAOOZDf1FGcT7Ce33gzjwhdY/CvvwbOxayjFH+pXf2MPZCMzz9lVJbY XMXJKxxaS0gYyfb/U6PHexertoK5yoZHMeI2FYRvDPlYDbAwLg4gdorDkcpnP9zA53 LRNtb0CIXYJzlTO3opAfjprQ3wRBwcGf247nyEew= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id EFF2BF8014C; Wed, 26 May 2021 04:46:24 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 555BFF80157; Wed, 26 May 2021 04:46:21 +0200 (CEST) Received: from relmlie5.idc.renesas.com (relmlor1.renesas.com [210.160.252.171]) by alsa1.perex.cz (Postfix) with ESMTP id 7D287F8011B for ; Wed, 26 May 2021 04:46:05 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 7D287F8011B Date: 26 May 2021 11:46:02 +0900 X-IronPort-AV: E=Sophos;i="5.82,330,1613401200"; d="scan'208";a="82429214" Received: from unknown (HELO relmlir6.idc.renesas.com) ([10.200.68.152]) by relmlie5.idc.renesas.com with ESMTP; 26 May 2021 11:46:02 +0900 Received: from mercury.renesas.com (unknown [10.166.252.133]) by relmlir6.idc.renesas.com (Postfix) with ESMTP id 78C884158054; Wed, 26 May 2021 11:46:02 +0900 (JST) Message-ID: <87tumqmcut.wl-kuninori.morimoto.gx@renesas.com> From: Kuninori Morimoto To: Mark Brown Subject: Re: [PATCH v2 2/7] ASoC: soc-core: add snd_soc_runtime_get_dai_fmt() In-Reply-To: References: <871racbx0w.wl-kuninori.morimoto.gx@renesas.com> <87y2ckaifm.wl-kuninori.morimoto.gx@renesas.com> User-Agent: Wanderlust/2.15.9 Emacs/26.3 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Linux-ALSA 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" Hi Mark > First up sorry it's taken me a while to respond to this - I > wanted to get it clear in my head what I thought the best > approach is here. I think your code here is good with a couple > of documentation tweaks: Thank you for your feedback / review, and no worry about taken times. This is very challeng patch, and I know you are always busy :) > > For example, some driver want to select format "automatically", > > but want to select other fields "manually", because of complex limitation. > > Or other example, in case of both CPU and Codec are possible to be > > clock provider, but the quality was different. > > In these case, user need/want to *manually* select each fields > > from Sound Card driver. > > > > It uses Sound Card specified fields preferentially, and try to select > > non-specific fields from CPU and Codec driver settings if driver had > > callbacks. > > In other words, we can select all dai_fmt via Sound Card driver > > same as before. > > I mentioned last time around the idea of having first and second > preferences for the DAIs, for things like "this will work but > only if you get the configuration exactly right". These patches > don't support that, they just treat everything the DAI reports as > being equally valid. I've actually come round to thinking that > might be OK for now but... (snip) > so that instead of worrying about formats that aren't quite > supported properly we just tell drivers not to list them for now > so if the system is relying on the framework to pick the DAI > format then we know it's one that's robust, we're not going to > choose one that the hardware in one of the devices isn't very > good at. Does that make sense to you? > > If we did do first and second choices we'd get an algorithm like: > > 1. Try to match both DAI's 1st choice, if match use that. > 2. Pick one DAI A, try it's 2nd choice with the other DAI B's 1st > choice. > 3. Swap and try 1st choice of A and 2nd choice of B. > 4. Try 2nd choices of both DAIs. > > but I think that might get too complicated and we'd end up stuck > if we ever wanted to change the algorithm since DTs that don't > specify a format may break if a different format is picked. If > we go with ranking every format individually it gets even more > complicated for both driver authors and the core. > > I think with the documentation tweak above your idea is a better > one for now, we can always go back later with more experience. Yes, we want to have robust code, and indeed it might be issue in the future if something happen around algorithm. To avoid such case, indeed having "priority" is nice idea, and indicating such things is indeed nesessary. OK, thank you for your feedback, I will update code, and repost it. Thank you for your help !! Best regards --- Kuninori Morimoto