Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4803299iob; Mon, 9 May 2022 01:54:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqFszGAnKpf0O5wj6tUTIsr/XBvyoCKt8KBvCPqRyu4XUuDvvwejC052M5YS3yoHp7JKpD X-Received: by 2002:a17:90a:4897:b0:1c7:5fce:cbcd with SMTP id b23-20020a17090a489700b001c75fcecbcdmr25272932pjh.45.1652086449925; Mon, 09 May 2022 01:54:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652086449; cv=none; d=google.com; s=arc-20160816; b=mvTMCb9NLyXPncTb03h5tHID0s+zkOEJ4now47d9PRJvd9j9nt+xfS0BGs1eYACmH6 FMuIyimAFrLVAknSvAKtoyrKkgmYj22+3c1nLKyCK13YwxnWbKrnkYBQ5du3ROjkvJ1m kmyz/3FLohGpIj24I+aermoV+wT38WWTteCVXBfI/WRUdDyYfcsHumr9z1UvweZgJH1D FKQc0zJUALD+ClGEZwkNpCMr9DxHYXAZef/KmMqhfWdZDPxYUR5iJW5ayVudhXVlsmbD lDNoKg9hfoIiplaY+c/G5ahAqH2Rm1uB4InsJ/QbNb1nx+K1/90Ifjq57jDEweqYaC8N 6P0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=cHbAYOoBseok48Czb5FKY8Bkxt0OSdif0K89/2KpUls=; b=Qm7/974v9g2ed4Csq8tMICn+g5DnYpbblWTR9tVsM2fytE6b37OkVVT9hHgiu+fOJd ql5L48Rstnke088jESYOaDbAfDUOcHqvh0Ux1+sPySvefSR5mjhCzmCF0jDRrI+j13J8 YmkTiI9BKO49oBZe8uY7JEh8WMmhQuNEUHrBP+BWvgsmCAHyC4b0I+guaLn+piur7ZXg JYz2uAWA2eLG+PhFX25Rw6OtNt9qJt9k118ZJzivlCbRg7vooVc44tOhQ2rS9noK1E9/ 3eolw2UiO0J7kvr32X9lVecZxfyHGsHFIneIeDnac4RbArfYgB6BN5zQlYBkCHjcihYK AH5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=fyh+VtUy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id c19-20020a170902849300b0015862deeb9dsi10267493plo.117.2022.05.09.01.54.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 01:54:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=fyh+VtUy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1181213128F; Mon, 9 May 2022 01:38:18 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1442110AbiEFOOO (ORCPT + 99 others); Fri, 6 May 2022 10:14:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1442074AbiEFOOI (ORCPT ); Fri, 6 May 2022 10:14:08 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B578969493; Fri, 6 May 2022 07:10:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: nfraprado) with ESMTPSA id 41D7C1F46710 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1651846204; bh=QSTdVIDTGCXlezHmH2+oiqQf0IZ7PXGw1SaggBY6/uM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fyh+VtUygnb9GB7tGAWE4+/MmdI32xBXFoaASg1PnEtQoRWab9mtk6k+P8QH6cfE1 MHt6Y246yXFhWyR2aOF13HlK0p2eb75MplA47CCmiD3Hu4zQX0Y24bM4Dalz3rbfQC HYI1wi3TbjH/5aQfWcOpqZKMSYgCdwzvGzidOEISocIxo8uASRjmWIVs8XxHQ9djDZ tXVhdn+r7znUVnA4CgEqFbN7D8bGaIxJGNsj2AINkxxlF9anY3TqiIu1qb6606ByUt rJRsg/FlGHNlS51Njw+KBR3ffLbd+xaBOjVs38VQ6Ng7vsTjCxU+C/7Fzsor2mb6/3 HYxPGh5huYPJg== Date: Fri, 6 May 2022 10:09:59 -0400 From: =?utf-8?B?TsOtY29sYXMgRi4gUi4gQS4=?= Prado To: Jiaxin Yu Cc: AngeloGioacchino Del Regno , Mark Brown , kernel@collabora.com, Krzysztof Kozlowski , Liam Girdwood , Matthias Brugger , Rob Herring , Shane Chien , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH 1/3] ASoC: dt-bindings: mediatek: mt8192: Add i2s-share properties Message-ID: <20220506140959.ldy32lyf5jbkkqj2@notapiano> References: <20220429203039.2207848-1-nfraprado@collabora.com> <20220429203039.2207848-2-nfraprado@collabora.com> <4826c824-40ce-5726-ed95-5be069233ca7@collabora.com> <20220505162537.byiwfe2ghomxhezl@notapiano> <559a1e189613484b8528dc4eaf19099e9162fcc6.camel@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <559a1e189613484b8528dc4eaf19099e9162fcc6.camel@mediatek.com> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 06, 2022 at 01:45:24PM +0800, Jiaxin Yu wrote: > On Thu, 2022-05-05 at 12:25 -0400, N?colas F. R. A. Prado wrote: > > > > > > On Thu, May 05, 2022 at 10:52:45AM +0200, AngeloGioacchino Del Regno > > wrote: > > > Il 05/05/22 10:48, Jiaxin Yu ha scritto: > > > > On Thu, 2022-05-05 at 10:08 +0200, AngeloGioacchino Del Regno > > > > wrote: > > > > > Il 29/04/22 22:30, N?colas F. R. A. Prado ha scritto: > > > > > > The Mediatek AFE PCM controller for MT8192 allows sharing of > > > > > > an I2S > > > > > > bus > > > > > > between two busses. Add a pattern for these properties in the > > > > > > dt-binding. > > > > > > > > > > > > Signed-off-by: N?colas F. R. A. Prado < > > > > > > nfraprado@collabora.com> > > > > > > --- > > > > > > > > > > > > Documentation/devicetree/bindings/sound/mt8192-afe- > > > > > > pcm.yaml | 5 > > > > > > +++++ > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/sound/mt8192- > > > > > > afe- > > > > > > pcm.yaml b/Documentation/devicetree/bindings/sound/mt8192- > > > > > > afe- > > > > > > pcm.yaml > > > > > > index 7a25bc9b8060..5b03c8dbf318 100644 > > > > > > --- a/Documentation/devicetree/bindings/sound/mt8192-afe- > > > > > > pcm.yaml > > > > > > +++ b/Documentation/devicetree/bindings/sound/mt8192-afe- > > > > > > pcm.yaml > > > > > > @@ -54,6 +54,11 @@ properties: > > > > > > - const: aud_infra_clk > > > > > > - const: aud_infra_26m_clk > > > > > > +patternProperties: > > > > > > + "^i2s[0-35-9]-share$": > > > > > > + description: Name of the I2S bus that is shared with > > > > > > this bus > > > > > > + pattern: "^I2S[0-35-9]$" > > > > > > + > > > > > > required: > > > > > > - compatible > > > > > > - interrupts > > > > > > > > > > > > > > > > The only other way of doing this would be to complicate this in > > > > > the > > > > > driver > > > > > so that we can do something like > > > > > > > > > > "i2s-share = <0 2>"; instead of i2s0-share = "I2S2"; > > > > > > > > > > ...and I don't think that this would be any more > > > > > straightforward than > > > > > the > > > > > provided way. > > > > > > > > > > There's an improvement that we can do to that pattern > > > > > description > > > > > though, > > > > > which would be explaining that declaring 'i2s0-share = "I2S2"' > > > > > means > > > > > that > > > > > I2S2's data pin will be used as DATA-OUT, while i2s0 is DATA- > > > > > IN. > > > > > > > > > > Another thing that comes to mind here is that this is a > > > > > MediaTek > > > > > specific > > > > > property and *not* a generic one, which means that both the > > > > > driver > > > > > and > > > > > this binding should be fixed to get a "mediatek," prefix, so, > > > > > this > > > > > property > > > > > should - in reality - be "mediatek,i2s[0-35-9]-share" instead. > > > > > > > > > > I think that everyone agrees about that, but let's see what the > > > > > others say. > > > > > > > > > > Cheers, > > > > > Angelo > > > > > > > > Hi Angelo, > > > > > > > > 'i2s0-share = "I2S2"' means that if we want use I2S0, there need > > > > open > > > > I2S2 to provide clock. Conversely, if we want to use I2S2, we > > > > don't > > > > need to open I2S0. However, MediaTek I2S0 and I2S2 hardware are > > > > generally designed as input. So usually we use 'i2s0-share = > > > > "I2S1"'. > > > > Even numbers represent input, odd numbers represent output. > > > > > > > > Yes, I think adding the "mediatek," prefix is the right way to > > > > define a > > > > non-generic property. > > > > > > > > Hi Jiaxin, > > > > thank you for the insights. > > > > > > > > Hello Jiaxin, > > > > > > if I get this correctly, i2s0-share = "I2S2" would be *invalid*... > > > as you > > > just explained, i2sX, where: > > > > > > X = even number -> always DATA IN > > > X = odd number -> always DATA OUT > > > > > > ...this means that the dt-binding needs a pattern to specify that > > > only odd > > > can be assigned to only even. > > > > So, the situation seems different at least on mt8192-asurada- > > spherion. > > Here, I2S8 is used for the headset microphone and I2S9 for the > > headset audio. > > Even for input and odd for output agree with Jiaxin's description. > > However, the > > input bus seems to be the main one, that is, disabling I2S8: > > > > amixer cset name='UL2_CH1 I2S8_CH1' 0 > > amixer cset name='UL2_CH2 I2S8_CH2' 0 > > > > not only disables the microphone but also the audio on the headset. > > If I add > > > > i2s9-share = "I2S8"; > > > > on the DT, then everything works, I can disable I2S8 without > > impacting the > > headset audio. So the pattern for the property on this platform is > > the opposite > > that Jiaxin mentioned. This tells me that we should keep the binding > > more > > generic (not assume where odds and evens go). I will still apply the > > other > > suggestions mentioned though. > > > > Thanks, > > N?colas > > > Hi N?colas, > > From software point, I2S8 and I2S9 belong to different hardware, so if > you turn off I2S8 with CMD1, of course it will not affect I2S9. > > CMD1: > amixer cset name='UL2_CH1 I2S8_CH1' 0 > amixer cset name='UL2_CH2 I2S8_CH2' 0 > > Frome hardware point, I2S9 will use(share) I2S8's clock. If we don't > want the user to perceive this, the driver need to help do something. > So this property 'i2s9-share = "I2S8";' will be added to inform the > driver. Hi Jiaxin, yes, that's what I figured. What I was saying is that for the binding, your example was i2s0-share = "I2S1" ^ even,input ^ odd,output while on mt8192-asurada-spherion the use case is i2s9-share = "I2S8"; ^ odd,output ^ even,input So Angelo's idea to require in the dt-binding that the left side is always even (input) and the right side always odd (based on your example), wouldn't work for my use case. Basically it's a question of whether the input always shares the clock from an output (your example), or if output always shares the clock from an input (my use case), or if both are valid. I'm taking from this that both are valid, so I won't add any such restriction in the dt-binding in the following version, but do let me know if this is not the case. Thanks, N?colas