Message ID | 20230602090322.1876359-4-alvin@pqrs.dk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp891610vqr; Fri, 2 Jun 2023 02:11:31 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ65mCmQSIGKbaXd5Ii0Fb/MzFedRibemmseHoIrFlmb8uL3NPeWJoHoxpIqNE/u3Xa+iuyM X-Received: by 2002:a9d:66c4:0:b0:6af:67d4:b37 with SMTP id t4-20020a9d66c4000000b006af67d40b37mr2313367otm.6.1685697091503; Fri, 02 Jun 2023 02:11:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685697091; cv=none; d=google.com; s=arc-20160816; b=nHma5wqKqFUVSbvYpniEkrFkFUmJYshvWXJFFrzcvinq/FxdxyH8oO+1Hh/MeEUzsc QrHSs0nZbgsfJHoLRDxkrpZqe+tWYka2Iy+bkEsL/Lu8opmkCXVdUVnC/qUoINLxtLLL YnoB3jz3aC/Sm15L40ifNNKb9/juDH0ANdrJPuf4TwX8yx2WokP+PC9yKNffmMnnsi87 rFrrqWeFcf9J1bQvZyodSwBJiOYM0QH9mv8dRmz+R46IutmIzFBFVhkEy26cMTxElO7b YCQ0KxDzgQmC8LP8aX4e5SwbGAdAYhwM/l3durYDZJM0oGci2q8jMn6ucQZ4mq+7ta2H t9zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ppOouDsw2ZJBp9Pb63smrW3GHRr3r6Vq+ntYkWdxiUU=; b=y6Olj8agkECgstSAPuQWd821x5e5VRvTehqLWGcDO2G8hYMtvkwZ9HeML3E4RIcXKU MOKND7p1O9MuTgHgbbmmBKhABT0cxIOATpSf8iDt2GiB+cucRkBRxMumdVHEG6KaedIa 0mRbSbt+0kDk4RGTOb7mRuJHevjwvdaRIdFJ8pCYqOAwjgZkrtp1ZY5sE76+pnfda/Il 6zpoNTMFSHwvif5hq6n798wFoFY72Fxal2h7g00PQ8uOgIc+WNts9PXRr26WbEjU1gRE eMvK6a0hVYBkSneoF9VOmk6gxfuogU1ZqW4YGLkUKC98LQLH1Y/ac9CNNsXl7lonh3Op 0dkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pqrs.dk header.s=google header.b=W7A072+4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z4-20020aa79904000000b0064e1b65f01dsi405118pff.237.2023.06.02.02.11.19; Fri, 02 Jun 2023 02:11:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@pqrs.dk header.s=google header.b=W7A072+4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234905AbjFBJFO (ORCPT <rfc822;limurcpp@gmail.com> + 99 others); Fri, 2 Jun 2023 05:05:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234812AbjFBJEM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 2 Jun 2023 05:04:12 -0400 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A888510CE for <linux-kernel@vger.kernel.org>; Fri, 2 Jun 2023 02:03:49 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5147e40bbbbso2630652a12.3 for <linux-kernel@vger.kernel.org>; Fri, 02 Jun 2023 02:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqrs.dk; s=google; t=1685696628; x=1688288628; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ppOouDsw2ZJBp9Pb63smrW3GHRr3r6Vq+ntYkWdxiUU=; b=W7A072+4L5LVDFH8xeLtIvjZhQinq7JukGEfUyDMsfu3Ltgt+G1BtIcw7ak1xEEHGl hAUqRouAfhJg//9Q+p9+8CJGUpYPUOHUrUGQLFmt/FgEgERYhiqusJZ/e0ZQu9O6eSc4 DmqOcdWC7yH1yDWj3Mg1nCVroO1VyUTPGMiUYTYRge94t/W+DcZlKQs6ItelryoyQ93m AEse3zS9XK/8Xz0VxP5mXPBfOf9dJj5ZVZ6CBqR4kiMc1Y4YCpeB0HjfKGSca7+rNxCz j7/GQhJUvGMovqQPDjqKV+Ah7gqBFlQFoVekcAxbhOM1gWsPj9HXrKGxgdKQrIOH6NjA ZO6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685696628; x=1688288628; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ppOouDsw2ZJBp9Pb63smrW3GHRr3r6Vq+ntYkWdxiUU=; b=F1G7rFHoau7zziPMyxc+A1NsvQCESqS4QdOoiTTuv7Xd/KfIUnbmKt0WdI0QCDJzko R2ACyvBIO7YxD70f/0efIHXx1+gCrObpxiHmMchSYuyra+/sFPzyw0W3z8fA8E25ksUA hXkQwc2lrRkEx81+ujsVmlh53bvUeqFVAIt3h2wS+KrPSh4hlJ9Q5drHpI+D/OK0el0w FzkvCe68ctsWQnuU2sfEXk/htC+Imk2PeZOhwkxasr4srtVgc1Ekx0+dyZ1h6PzTiNS8 7O8F3/3W4ohz5BRlZ0s1FUQoCICdyiSQ15f9qWiXkiv9qM46zgDRkyTO7mhhRRb3nU5F l6Aw== X-Gm-Message-State: AC+VfDy5lSEcglMz7ddy4swHKbqWWf4UBLKXty6TJTlIpl5imu2MtL6F d73wfbgd9MFqLejVOgDlIjQD2g== X-Received: by 2002:a17:907:d17:b0:966:eb8:2f12 with SMTP id gn23-20020a1709070d1700b009660eb82f12mr10334273ejc.11.1685696628034; Fri, 02 Jun 2023 02:03:48 -0700 (PDT) Received: from localhost.localdomain (80.71.142.18.ipv4.parknet.dk. [80.71.142.18]) by smtp.gmail.com with ESMTPSA id w23-20020a170906385700b009707fa1c316sm488031ejc.213.2023.06.02.02.03.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jun 2023 02:03:47 -0700 (PDT) From: =?utf-8?q?Alvin_=C5=A0ipraga?= <alvin@pqrs.dk> To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Cc: =?utf-8?q?Alvin_=C5=A0ipraga?= <alsi@bang-olufsen.dk>, alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/4] ASoC: audio-graph-card2: parse symmetric-clock-roles property Date: Fri, 2 Jun 2023 11:03:20 +0200 Message-Id: <20230602090322.1876359-4-alvin@pqrs.dk> X-Mailer: git-send-email 2.40.0 In-Reply-To: <20230602090322.1876359-1-alvin@pqrs.dk> References: <20230602090322.1876359-1-alvin@pqrs.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767581513320180172?= X-GMAIL-MSGID: =?utf-8?q?1767581513320180172?= |
Series |
ASoC: support dai-links with symmetric clock roles
|
|
Commit Message
Alvin Šipraga
June 2, 2023, 9:03 a.m. UTC
From: Alvin Šipraga <alsi@bang-olufsen.dk> The property, when set, specifies that both ends of the dai-link should have the same clock consumer/provider roles. Like with parsing of DAI format, the property can be specified in multiple places: ports { (A) port { (B) endpoint { (C) }; }; }; So each place has to be checked. In case the clock roles are symmetric, there is then no need to flip the role when parsing the DAI format on the CPU side, as it should then be the same on the Codec side. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> --- sound/soc/generic/audio-graph-card2.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
Comments
Hi Alvin > --- a/sound/soc/generic/audio-graph-card2.c > +++ b/sound/soc/generic/audio-graph-card2.c (snip) > /* > * convert bit_frame > * We need to flip clock_provider if it was CPU node, > * because it is Codec base. > */ > daiclk = snd_soc_daifmt_clock_provider_from_bitmap(bit_frame); > - if (is_cpu_node) > + if (is_cpu_node && !dai_link->symmetric_clock_roles) > daiclk = snd_soc_daifmt_clock_provider_flipped(daiclk); > > dai_link->dai_fmt = daifmt | daiclk; Hmm ? I'm confusing [2/4] patch handling fliping, and [3/4] also handling fliping. Nothing changed ? Current SND_SOC_DAIFMT_xx_xx are very confusable, framework and driver are different (flipped). and also, audio-graph-card2 is using intuitive DT settings (need flip for CPU). Thank you for your help !! Best regards --- Kuninori Morimoto
Hi Kuninori, On Mon, Jun 05, 2023 at 12:35:56AM +0000, Kuninori Morimoto wrote: > > Hi Alvin > > > --- a/sound/soc/generic/audio-graph-card2.c > > +++ b/sound/soc/generic/audio-graph-card2.c > (snip) > > /* > > * convert bit_frame > > * We need to flip clock_provider if it was CPU node, > > * because it is Codec base. > > */ > > daiclk = snd_soc_daifmt_clock_provider_from_bitmap(bit_frame); > > - if (is_cpu_node) > > + if (is_cpu_node && !dai_link->symmetric_clock_roles) > > daiclk = snd_soc_daifmt_clock_provider_flipped(daiclk); > > > > dai_link->dai_fmt = daifmt | daiclk; > > Hmm ? I'm confusing > [2/4] patch handling fliping, and [3/4] also handling fliping. > Nothing changed ? Yes, I agree it seems wrong. Let me try and explain what is going on. First take a look at the original snd_soc_runtime_set_dai_fmt: int snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd, unsigned int dai_fmt) { struct snd_soc_dai_link *dai_link = rtd->dai_link; struct snd_soc_dai *cpu_dai; struct snd_soc_dai *codec_dai; unsigned int i; int ret; if (!dai_fmt) return 0; for_each_rtd_codec_dais(rtd, i, codec_dai) { ret = snd_soc_dai_set_fmt(codec_dai, dai_fmt); if (ret != 0 && ret != -ENOTSUPP) return ret; } /* Flip the polarity for the "CPU" end of link */ dai_fmt = snd_soc_daifmt_clock_provider_flipped(dai_fmt); for_each_rtd_cpu_dais(rtd, i, cpu_dai) { ret = snd_soc_dai_set_fmt(cpu_dai, dai_fmt); if (ret != 0 && ret != -ENOTSUPP) return ret; } return 0; } ... which is called by the core in soc_init_pcm_runtime: static int soc_init_pcm_runtime(struct snd_soc_card *card, struct snd_soc_pcm_runtime *rtd) { struct snd_soc_dai_link *dai_link = rtd->dai_link; /* ... */ snd_soc_runtime_get_dai_fmt(rtd); ret = snd_soc_runtime_set_dai_fmt(rtd, dai_link->dai_fmt); if (ret) return ret; /* ... */ } From the above I conclude that the clock role expressed by dai_link->dai_fmt is "as applied to the codec", i.e. snd_soc_runtime_set_dai_fmt does not flip the value before applying it on the codec side. When applying it to the CPU side, the roles are flipped. > > Current SND_SOC_DAIFMT_xx_xx are very confusable, > framework and driver are different (flipped). > and also, audio-graph-card2 is using intuitive DT settings > (need flip for CPU). Now consider audio-graph-card2. Except for DPCM backends, it always parses the DAI format on the CPU side. Since dai_link->dai_fmt is flipped by the ASoC core when applying format to the CPU, card2 is flipping the parsed value before storing it in dai_link->dai_fmt so that it is correct. audio-graph-card2 -. v -1 * -1 = 1 ^ '- ASoC core But with patch 2/4 of this series, symmetric_clock_roles == 1 means that the ASoC core doesn't flip it. In fact, it means that the role is the same both "as applied to the codec" and "as applied to the CPU". So no flipping should happen, neither in card2 nor in ASoC core. CPU and codec clock consumer/provider roles are symmetric. e.g. if CPU is a bitclock consumer then so is the codec, and nothing needs flipping. I hope that is clear now. Kind regards, Alvin
diff --git a/sound/soc/generic/audio-graph-card2.c b/sound/soc/generic/audio-graph-card2.c index 25aa79dd55b3..9b4ebfd0c0b6 100644 --- a/sound/soc/generic/audio-graph-card2.c +++ b/sound/soc/generic/audio-graph-card2.c @@ -721,13 +721,18 @@ static void graph_link_init(struct asoc_simple_priv *priv, if (of_node_name_eq(ports, "ports")) graph_parse_daifmt(ports, &daifmt, &bit_frame); /* (A) */ + if (of_property_read_bool(ep, "symmetric-clock-roles") || + of_property_read_bool(port, "symmetric-clock-roles") || + of_property_read_bool(ports, "symmetric-clock-roles")) + dai_link->symmetric_clock_roles = 1; + /* * convert bit_frame * We need to flip clock_provider if it was CPU node, * because it is Codec base. */ daiclk = snd_soc_daifmt_clock_provider_from_bitmap(bit_frame); - if (is_cpu_node) + if (is_cpu_node && !dai_link->symmetric_clock_roles) daiclk = snd_soc_daifmt_clock_provider_flipped(daiclk); dai_link->dai_fmt = daifmt | daiclk;