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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 A766AC432BE for ; Fri, 20 Aug 2021 07:05:55 +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 1F8A261056 for ; Fri, 20 Aug 2021 07:05:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1F8A261056 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=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 C35FD16A6; Fri, 20 Aug 2021 09:05:03 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz C35FD16A6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1629443153; bh=oRgVkx+6GMWt5n5ZIY2zFuPqLFtK9CK5Zy8qCUC2+r8=; h=From:To:Subject:Date:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=T39NSNv8+sEDURuOGv3b5cxjCke1B1D73eSalncOjezJMF1Q20kHeaNlgMDzSiiK2 WjgMzlIgbw4Z80J8qh/t3AOHxCb+TYbcvBvQQ4394hQBT5kPeHiZHvGm/C2FDet+uy Fsn8sN2wqX8MiyNtmM+n3w45uRiVZ+xXW1tozn6Y= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 0D79EF8050F; Fri, 20 Aug 2021 09:02:26 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id E0C12F8026D; Thu, 19 Aug 2021 15:53:05 +0200 (CEST) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 6E200F800F8 for ; Thu, 19 Aug 2021 15:52:58 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 6E200F800F8 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BVG+5HrA" Received: by mail-ej1-x62b.google.com with SMTP id d11so13072217eja.8 for ; Thu, 19 Aug 2021 06:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=/HYaakT71hwEdcXvkxwyQsillUjSwTO59JhdjV9n6y4=; b=BVG+5HrApNRX9+03fK0jt38W6Ps+UyhCQADZcdZe1QVPyVsrWh+RlxWohzju5i7IfV IGO9cvRFPjCMp+i8l1kXqOyMt3QsOoyEyu6f7xLSY7Vs2LzpmsgFEuz3zLkK/6CTLrdj F7nnKRo3DDRugBTcoyY2Rss9o2yUYfy9fQZb1Ep0lkSXVE8XYZuQuYlYw0PKM9C5vj1A w2VGwE8UO4owDU0hs4h1DKqlg8np9j+vKv5jrARah7QGVhcuNxgx2j2bpqUMvH8vp+eV vRUi7Sq+lk179LXgirigXKAzF0UqCguYyHo0hgqud7AZMK6uB2DFeBV2HxFX1QzBgUO8 +utQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/HYaakT71hwEdcXvkxwyQsillUjSwTO59JhdjV9n6y4=; b=Anx3JKbPM5f4XnnLPlRM/QCM0xarJYev/4q1oAMxdRwwU3H+N2JXU/kqnKY6wtFeFG uCuE06xBib3ahqBSftzSG1DlOTw8M7DZvqKLLlpTvV0B4goEfrtd3bGbCcPxH/4FVBgH ht/T43JfJ8SUlR6Z8wFIEObSQiirKMwcePYMSiriQ8zMfQ2qduh9IF/7hMlJQXehQWOq fVjzciiiOlZmCFDSqWxUwS/cbFIYwaxF2A0fc+VNN+KPQwTumuBhYLaIkFu9S7ntyrgX KWcz1XlX2JQ0m+CrM3VhFDW9vyXQRyBjGBvbcpITHBtfJ+Ghhx7rF3Xlvyap5fyD/MF4 uiIQ== X-Gm-Message-State: AOAM531hjIMpmEHRRJ4FUutLRNMH1cYGtcnLjAS6pY9fEDFAED2jaNfd UghJ0NmGeeAmcr009kGrI5g= X-Google-Smtp-Source: ABdhPJxf6vkzIJ5gvRxJJnkoE76NF/NsXfuA1qI+2XbKik7L6dd//lHk57lp40vP12GLenGbbQ1fCQ== X-Received: by 2002:a17:906:1dd6:: with SMTP id v22mr9418467ejh.226.1629381176818; Thu, 19 Aug 2021 06:52:56 -0700 (PDT) Received: from archbook.localnet (84-72-105-84.dclient.hispeed.ch. [84.72.105.84]) by smtp.gmail.com with ESMTPSA id y23sm1294480ejp.115.2021.08.19.06.52.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 06:52:56 -0700 (PDT) From: Nicolas Frattaroli To: Liam Girdwood , Mark Brown , Rob Herring , Heiko Stuebner , Robin Murphy Subject: Re: [PATCH 2/4] dt-bindings: sound: add rockchip i2s-tdm binding Date: Thu, 19 Aug 2021 15:52:55 +0200 Message-ID: <2412250.zZEsDtmPgG@archbook> In-Reply-To: References: <20210817101119.423853-1-frattaroli.nicolas@gmail.com> <20210817101119.423853-3-frattaroli.nicolas@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Fri, 20 Aug 2021 09:02:12 +0200 Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org 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" On Donnerstag, 19. August 2021 14:08:36 CEST Robin Murphy wrote: > On 2021-08-17 11:11, Nicolas Frattaroli wrote: > > + rockchip,trcm-sync: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Which lrck/bclk clocks each direction will sync to. You should use > > the + constants in > > + oneOf: > > + - const: 0 > > + description: > > + RK_TRCM_TXRX. Use both the TX and the RX clock for TX and RX. > > + - const: 1 > > + description: > > + RK_TRCM_TX. Use only the TX clock for TX and RX. > > + - const: 2 > > + description: > > + RK_TRCM_RX. Use only the RX clock for TX and RX. > > I wonder if that might make sense to have boolean properties to describe > the latter two cases (which would effectively be mutually-exclusive), > rather than a magic number? Or possibly even just make the respective > clocks optional, if this is something which would be done per-SoC rather > than per-board? > >From what I know from downstream vendor device trees, these are per board, not for the SoC as a whole. There are I2S/TDM controllers on the SoC which I think are hardwired to certain other IP blocks, such as I2S0 being connected to HDMI, but I2S1 can be routed outside of the SoC where these come into play I believe. As for making them boolean properties, I'd rather not. If I were to make it two mutually exclusive booleans, this would result in 4 possible states rather than 3, and require complexity to check it both in the schema and in the probe function. Like this, I can get away with a switch case that has a fallthrough, and a list of consts in the schema. > > + > > + "#sound-dai-cells": > > + const: 0 > > + > > + rockchip,no-dmaengine: > > + description: > > + If present, driver will not register a pcm dmaengine, only the dai. > > + If the dai is part of multi-dais, the property should be present. > > + type: boolean > > That sounds a lot more like a policy decision specific to the Linux > driver implementation, than something which really belongs in DT as a > description of the platform. I agree. Should I be refactoring this into a module parameter or something along those lines? I'm unsure of where this goes. > > > + > > + rockchip,playback-only: > > + description: Specify that the controller only has playback > > capability. > > + type: boolean > > + > > + rockchip,capture-only: > > + description: Specify that the controller only has capture capability. > > + type: boolean > > Could those be inferred from the compatible string, or are there cases > where you have multiple instances of the IP block in different > configurations within the same SoC? (Or if it's merely reflecting > whether the respective interface is actually wired up externally, could > that be inferred from the attached codec?) > > Robin. > They can't be inferred from the SoC because there are indeed multiple instances of this IP block in different configurations on the same SoC. The RK3566 and RK3568 have four in total, of two different categories, each being able to be configured for a different format (though the number of channels and available formats vary for the two categories, one group only supports I2S and PCM with two channels) The particular configuration may even vary per-board; an I2S/TDM controller may be connected to an external codec which does not support capture, whereas on another board it may be connected to one that does. As an example, if I understand it correctly, I2S3 on the RK3566 and RK3568 can do 2 channels RX and TX in I2S mode, but only 2 channels either RX or TX in PCM mode, but I'm unsure of the language in the (still not public) documentation I have. Regards, Nicolas Frattaroli 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 493C8C4338F for ; Thu, 19 Aug 2021 13:53:21 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 14F8F610FF for ; Thu, 19 Aug 2021 13:53:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 14F8F610FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Oo4I1Pt5/qv/y0GWQqtVBatJFwrwSfQj1RuRDJ6OgVs=; b=kqaNUF/3HFM5EI HgozfFfp/BGSrIyDlSK8e2+hFBY40wefIKp0ErvI69a1asJeD7/gYwCOYQo6EfksQTagFswO4KUYg yYRgV2CdB8m+c8cMCdHDHK9tSu9K6h2y4Kb6jHtWH9R3t+VARLk93MBSeEvEKf2/w50sEF12Q8N81 5S/FwPoLZ7wV/4DWhQuqVJvrcWRpD94thAvlfeJ0Ih3GnajEKWv2JJbNUMH6Jeinwi5x2/4zgzjP2 xSlqlpEt0S5C35U1u5/uqKw2+Sxr0q1KGTGFzExDgrEeKXjFkBqva2Z6EW4ltfo0dc+POq73eIF8H fAR80bOV7hsKlzr9oujA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGiTs-008Wct-Tk; Thu, 19 Aug 2021 13:53:16 +0000 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGiTb-008WXo-2R; Thu, 19 Aug 2021 13:53:00 +0000 Received: by mail-ej1-x62c.google.com with SMTP id z20so13096854ejf.5; Thu, 19 Aug 2021 06:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=/HYaakT71hwEdcXvkxwyQsillUjSwTO59JhdjV9n6y4=; b=BVG+5HrApNRX9+03fK0jt38W6Ps+UyhCQADZcdZe1QVPyVsrWh+RlxWohzju5i7IfV IGO9cvRFPjCMp+i8l1kXqOyMt3QsOoyEyu6f7xLSY7Vs2LzpmsgFEuz3zLkK/6CTLrdj F7nnKRo3DDRugBTcoyY2Rss9o2yUYfy9fQZb1Ep0lkSXVE8XYZuQuYlYw0PKM9C5vj1A w2VGwE8UO4owDU0hs4h1DKqlg8np9j+vKv5jrARah7QGVhcuNxgx2j2bpqUMvH8vp+eV vRUi7Sq+lk179LXgirigXKAzF0UqCguYyHo0hgqud7AZMK6uB2DFeBV2HxFX1QzBgUO8 +utQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/HYaakT71hwEdcXvkxwyQsillUjSwTO59JhdjV9n6y4=; b=ZUKwr2jCZssDnBISYoMI78Jre45ZfFsJmWI2dKskUY3ZdKwv8F/Di6BMqlD1DUa5RF VOdsBN4M9FJkGA/H+EM1TWXscIIfTBICj2v7YnpS9PraTMMbBGD40Q7QkwgvVTgooDtb 7ggYZhJHrdCJRt4uoqD0Htgr4J+v7rvuN9iHNe+UeoA8C0idosvsBJ1SsDFwuBOmksS/ vCabUjjb+bws3Sc+4YHjXUa8UlbcRrY9VFiWBA97DBATtSzVP7tuLcu88i0vwMZlYpMO 4/sA29TFXIRQJ09Y9/dW5N2uInf3fUji6wd6wTBaOOZVrUBfi1jEQQycw76VF4t2y/6m jzDQ== X-Gm-Message-State: AOAM533MeteXW2G5Ke67A1eElcwzXtQyNiU9bt3bkAxkJFGw2qcm/gd1 rWBhWXfIb7w1dE5u0O1Nspk= X-Google-Smtp-Source: ABdhPJxf6vkzIJ5gvRxJJnkoE76NF/NsXfuA1qI+2XbKik7L6dd//lHk57lp40vP12GLenGbbQ1fCQ== X-Received: by 2002:a17:906:1dd6:: with SMTP id v22mr9418467ejh.226.1629381176818; Thu, 19 Aug 2021 06:52:56 -0700 (PDT) Received: from archbook.localnet (84-72-105-84.dclient.hispeed.ch. [84.72.105.84]) by smtp.gmail.com with ESMTPSA id y23sm1294480ejp.115.2021.08.19.06.52.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 06:52:56 -0700 (PDT) From: Nicolas Frattaroli To: Liam Girdwood , Mark Brown , Rob Herring , Heiko Stuebner , Robin Murphy Cc: alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] dt-bindings: sound: add rockchip i2s-tdm binding Date: Thu, 19 Aug 2021 15:52:55 +0200 Message-ID: <2412250.zZEsDtmPgG@archbook> In-Reply-To: References: <20210817101119.423853-1-frattaroli.nicolas@gmail.com> <20210817101119.423853-3-frattaroli.nicolas@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210819_065259_184766_8A762050 X-CRM114-Status: GOOD ( 33.90 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Donnerstag, 19. August 2021 14:08:36 CEST Robin Murphy wrote: > On 2021-08-17 11:11, Nicolas Frattaroli wrote: > > + rockchip,trcm-sync: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Which lrck/bclk clocks each direction will sync to. You should use > > the + constants in > > + oneOf: > > + - const: 0 > > + description: > > + RK_TRCM_TXRX. Use both the TX and the RX clock for TX and RX. > > + - const: 1 > > + description: > > + RK_TRCM_TX. Use only the TX clock for TX and RX. > > + - const: 2 > > + description: > > + RK_TRCM_RX. Use only the RX clock for TX and RX. > > I wonder if that might make sense to have boolean properties to describe > the latter two cases (which would effectively be mutually-exclusive), > rather than a magic number? Or possibly even just make the respective > clocks optional, if this is something which would be done per-SoC rather > than per-board? > >From what I know from downstream vendor device trees, these are per board, not for the SoC as a whole. There are I2S/TDM controllers on the SoC which I think are hardwired to certain other IP blocks, such as I2S0 being connected to HDMI, but I2S1 can be routed outside of the SoC where these come into play I believe. As for making them boolean properties, I'd rather not. If I were to make it two mutually exclusive booleans, this would result in 4 possible states rather than 3, and require complexity to check it both in the schema and in the probe function. Like this, I can get away with a switch case that has a fallthrough, and a list of consts in the schema. > > + > > + "#sound-dai-cells": > > + const: 0 > > + > > + rockchip,no-dmaengine: > > + description: > > + If present, driver will not register a pcm dmaengine, only the dai. > > + If the dai is part of multi-dais, the property should be present. > > + type: boolean > > That sounds a lot more like a policy decision specific to the Linux > driver implementation, than something which really belongs in DT as a > description of the platform. I agree. Should I be refactoring this into a module parameter or something along those lines? I'm unsure of where this goes. > > > + > > + rockchip,playback-only: > > + description: Specify that the controller only has playback > > capability. > > + type: boolean > > + > > + rockchip,capture-only: > > + description: Specify that the controller only has capture capability. > > + type: boolean > > Could those be inferred from the compatible string, or are there cases > where you have multiple instances of the IP block in different > configurations within the same SoC? (Or if it's merely reflecting > whether the respective interface is actually wired up externally, could > that be inferred from the attached codec?) > > Robin. > They can't be inferred from the SoC because there are indeed multiple instances of this IP block in different configurations on the same SoC. The RK3566 and RK3568 have four in total, of two different categories, each being able to be configured for a different format (though the number of channels and available formats vary for the two categories, one group only supports I2S and PCM with two channels) The particular configuration may even vary per-board; an I2S/TDM controller may be connected to an external codec which does not support capture, whereas on another board it may be connected to one that does. As an example, if I understand it correctly, I2S3 on the RK3566 and RK3568 can do 2 channels RX and TX in I2S mode, but only 2 channels either RX or TX in PCM mode, but I'm unsure of the language in the (still not public) documentation I have. Regards, Nicolas Frattaroli _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 5D07CC4338F for ; Thu, 19 Aug 2021 13:54:53 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 2EB29610FF for ; Thu, 19 Aug 2021 13:54:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2EB29610FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=N3fk36bimBVxc2Be8xwdfGsjzLhT21/lY9y627M0f24=; b=xZ6B6OL9Rl9ink ySsSxyGv8SqGtz+Ne0cZ+cDQe3r5jSUsxoadZv6GNBG9X4lx7kltY2pQeux/O+WtBZrf+cU0y+zmz c72aUvfhpWTFJrXfWS78gNXEPPMdJsOIcAUPbk2zMzOjzNecGahAc+PitThFs6mty71FWAsVo8brf dPH70VeMashik0MGY16dVJ43Xxz15qVPHIRxIJJDTzAGJizNjajMB6Gd8piTV9lf8R4tcGkaaT/IZ 8SljR+HtV6Z14W2bww9T2SmsNC3hxFOU4Cr51smg5d1Kl1oKpjatrYL/gHS3kI7OWTDzmR4y+4OSI SutRddJcKsuA7u3/IOAw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGiTg-008WZY-VW; Thu, 19 Aug 2021 13:53:05 +0000 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGiTb-008WXo-2R; Thu, 19 Aug 2021 13:53:00 +0000 Received: by mail-ej1-x62c.google.com with SMTP id z20so13096854ejf.5; Thu, 19 Aug 2021 06:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=/HYaakT71hwEdcXvkxwyQsillUjSwTO59JhdjV9n6y4=; b=BVG+5HrApNRX9+03fK0jt38W6Ps+UyhCQADZcdZe1QVPyVsrWh+RlxWohzju5i7IfV IGO9cvRFPjCMp+i8l1kXqOyMt3QsOoyEyu6f7xLSY7Vs2LzpmsgFEuz3zLkK/6CTLrdj F7nnKRo3DDRugBTcoyY2Rss9o2yUYfy9fQZb1Ep0lkSXVE8XYZuQuYlYw0PKM9C5vj1A w2VGwE8UO4owDU0hs4h1DKqlg8np9j+vKv5jrARah7QGVhcuNxgx2j2bpqUMvH8vp+eV vRUi7Sq+lk179LXgirigXKAzF0UqCguYyHo0hgqud7AZMK6uB2DFeBV2HxFX1QzBgUO8 +utQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/HYaakT71hwEdcXvkxwyQsillUjSwTO59JhdjV9n6y4=; b=ZUKwr2jCZssDnBISYoMI78Jre45ZfFsJmWI2dKskUY3ZdKwv8F/Di6BMqlD1DUa5RF VOdsBN4M9FJkGA/H+EM1TWXscIIfTBICj2v7YnpS9PraTMMbBGD40Q7QkwgvVTgooDtb 7ggYZhJHrdCJRt4uoqD0Htgr4J+v7rvuN9iHNe+UeoA8C0idosvsBJ1SsDFwuBOmksS/ vCabUjjb+bws3Sc+4YHjXUa8UlbcRrY9VFiWBA97DBATtSzVP7tuLcu88i0vwMZlYpMO 4/sA29TFXIRQJ09Y9/dW5N2uInf3fUji6wd6wTBaOOZVrUBfi1jEQQycw76VF4t2y/6m jzDQ== X-Gm-Message-State: AOAM533MeteXW2G5Ke67A1eElcwzXtQyNiU9bt3bkAxkJFGw2qcm/gd1 rWBhWXfIb7w1dE5u0O1Nspk= X-Google-Smtp-Source: ABdhPJxf6vkzIJ5gvRxJJnkoE76NF/NsXfuA1qI+2XbKik7L6dd//lHk57lp40vP12GLenGbbQ1fCQ== X-Received: by 2002:a17:906:1dd6:: with SMTP id v22mr9418467ejh.226.1629381176818; Thu, 19 Aug 2021 06:52:56 -0700 (PDT) Received: from archbook.localnet (84-72-105-84.dclient.hispeed.ch. [84.72.105.84]) by smtp.gmail.com with ESMTPSA id y23sm1294480ejp.115.2021.08.19.06.52.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 06:52:56 -0700 (PDT) From: Nicolas Frattaroli To: Liam Girdwood , Mark Brown , Rob Herring , Heiko Stuebner , Robin Murphy Cc: alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] dt-bindings: sound: add rockchip i2s-tdm binding Date: Thu, 19 Aug 2021 15:52:55 +0200 Message-ID: <2412250.zZEsDtmPgG@archbook> In-Reply-To: References: <20210817101119.423853-1-frattaroli.nicolas@gmail.com> <20210817101119.423853-3-frattaroli.nicolas@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210819_065259_184766_8A762050 X-CRM114-Status: GOOD ( 33.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Donnerstag, 19. August 2021 14:08:36 CEST Robin Murphy wrote: > On 2021-08-17 11:11, Nicolas Frattaroli wrote: > > + rockchip,trcm-sync: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Which lrck/bclk clocks each direction will sync to. You should use > > the + constants in > > + oneOf: > > + - const: 0 > > + description: > > + RK_TRCM_TXRX. Use both the TX and the RX clock for TX and RX. > > + - const: 1 > > + description: > > + RK_TRCM_TX. Use only the TX clock for TX and RX. > > + - const: 2 > > + description: > > + RK_TRCM_RX. Use only the RX clock for TX and RX. > > I wonder if that might make sense to have boolean properties to describe > the latter two cases (which would effectively be mutually-exclusive), > rather than a magic number? Or possibly even just make the respective > clocks optional, if this is something which would be done per-SoC rather > than per-board? > >From what I know from downstream vendor device trees, these are per board, not for the SoC as a whole. There are I2S/TDM controllers on the SoC which I think are hardwired to certain other IP blocks, such as I2S0 being connected to HDMI, but I2S1 can be routed outside of the SoC where these come into play I believe. As for making them boolean properties, I'd rather not. If I were to make it two mutually exclusive booleans, this would result in 4 possible states rather than 3, and require complexity to check it both in the schema and in the probe function. Like this, I can get away with a switch case that has a fallthrough, and a list of consts in the schema. > > + > > + "#sound-dai-cells": > > + const: 0 > > + > > + rockchip,no-dmaengine: > > + description: > > + If present, driver will not register a pcm dmaengine, only the dai. > > + If the dai is part of multi-dais, the property should be present. > > + type: boolean > > That sounds a lot more like a policy decision specific to the Linux > driver implementation, than something which really belongs in DT as a > description of the platform. I agree. Should I be refactoring this into a module parameter or something along those lines? I'm unsure of where this goes. > > > + > > + rockchip,playback-only: > > + description: Specify that the controller only has playback > > capability. > > + type: boolean > > + > > + rockchip,capture-only: > > + description: Specify that the controller only has capture capability. > > + type: boolean > > Could those be inferred from the compatible string, or are there cases > where you have multiple instances of the IP block in different > configurations within the same SoC? (Or if it's merely reflecting > whether the respective interface is actually wired up externally, could > that be inferred from the attached codec?) > > Robin. > They can't be inferred from the SoC because there are indeed multiple instances of this IP block in different configurations on the same SoC. The RK3566 and RK3568 have four in total, of two different categories, each being able to be configured for a different format (though the number of channels and available formats vary for the two categories, one group only supports I2S and PCM with two channels) The particular configuration may even vary per-board; an I2S/TDM controller may be connected to an external codec which does not support capture, whereas on another board it may be connected to one that does. As an example, if I understand it correctly, I2S3 on the RK3566 and RK3568 can do 2 channels RX and TX in I2S mode, but only 2 channels either RX or TX in PCM mode, but I'm unsure of the language in the (still not public) documentation I have. Regards, Nicolas Frattaroli _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 0B6ECC4338F for ; Thu, 19 Aug 2021 13:53:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D43E2610FF for ; Thu, 19 Aug 2021 13:52:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238498AbhHSNxf (ORCPT ); Thu, 19 Aug 2021 09:53:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240102AbhHSNxe (ORCPT ); Thu, 19 Aug 2021 09:53:34 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44E8EC061575; Thu, 19 Aug 2021 06:52:58 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id lo4so13079379ejb.7; Thu, 19 Aug 2021 06:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=/HYaakT71hwEdcXvkxwyQsillUjSwTO59JhdjV9n6y4=; b=BVG+5HrApNRX9+03fK0jt38W6Ps+UyhCQADZcdZe1QVPyVsrWh+RlxWohzju5i7IfV IGO9cvRFPjCMp+i8l1kXqOyMt3QsOoyEyu6f7xLSY7Vs2LzpmsgFEuz3zLkK/6CTLrdj F7nnKRo3DDRugBTcoyY2Rss9o2yUYfy9fQZb1Ep0lkSXVE8XYZuQuYlYw0PKM9C5vj1A w2VGwE8UO4owDU0hs4h1DKqlg8np9j+vKv5jrARah7QGVhcuNxgx2j2bpqUMvH8vp+eV vRUi7Sq+lk179LXgirigXKAzF0UqCguYyHo0hgqud7AZMK6uB2DFeBV2HxFX1QzBgUO8 +utQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/HYaakT71hwEdcXvkxwyQsillUjSwTO59JhdjV9n6y4=; b=LotufcwczG5DolTfY7J1TFerP/Db/QLWe+IGDLqcK5+k97Gb1ao1nl0E5pN0+TVX5E BWv+WWhF6xCkbh09Qpfuc8DOnx6NC65HbQ9EKHUtUvQIUgl4dK6fU4gL7GJ2K52LQmjk erYPqwsMh+rh7Huv4M7C0XVRYQoIi+yQHRbD/Mn7vDYnM3VaSTRG89v6savN9rKyhACq aoaBD8o6R9X3fp6ol2FzwI+x1Jftm3nnCoA50qt2qewWoMsdhzS5a28k7qKZbLBSbyhy f7YpSkLgCl5aHpAZX+Xn/CSM9a7vFy5aVQ2Jqa3njq5+ESam4XYXy8UDG1PhQr4VAooJ 09hQ== X-Gm-Message-State: AOAM530BWg66EweUgtRo5lUv58Cl0d5U6Opc5aPqvjEYjoqXSefmuHah k8uxyk19v0jjKsIAR39XBag= X-Google-Smtp-Source: ABdhPJxf6vkzIJ5gvRxJJnkoE76NF/NsXfuA1qI+2XbKik7L6dd//lHk57lp40vP12GLenGbbQ1fCQ== X-Received: by 2002:a17:906:1dd6:: with SMTP id v22mr9418467ejh.226.1629381176818; Thu, 19 Aug 2021 06:52:56 -0700 (PDT) Received: from archbook.localnet (84-72-105-84.dclient.hispeed.ch. [84.72.105.84]) by smtp.gmail.com with ESMTPSA id y23sm1294480ejp.115.2021.08.19.06.52.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 06:52:56 -0700 (PDT) From: Nicolas Frattaroli To: Liam Girdwood , Mark Brown , Rob Herring , Heiko Stuebner , Robin Murphy Cc: alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] dt-bindings: sound: add rockchip i2s-tdm binding Date: Thu, 19 Aug 2021 15:52:55 +0200 Message-ID: <2412250.zZEsDtmPgG@archbook> In-Reply-To: References: <20210817101119.423853-1-frattaroli.nicolas@gmail.com> <20210817101119.423853-3-frattaroli.nicolas@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Donnerstag, 19. August 2021 14:08:36 CEST Robin Murphy wrote: > On 2021-08-17 11:11, Nicolas Frattaroli wrote: > > + rockchip,trcm-sync: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Which lrck/bclk clocks each direction will sync to. You should use > > the + constants in > > + oneOf: > > + - const: 0 > > + description: > > + RK_TRCM_TXRX. Use both the TX and the RX clock for TX and RX. > > + - const: 1 > > + description: > > + RK_TRCM_TX. Use only the TX clock for TX and RX. > > + - const: 2 > > + description: > > + RK_TRCM_RX. Use only the RX clock for TX and RX. > > I wonder if that might make sense to have boolean properties to describe > the latter two cases (which would effectively be mutually-exclusive), > rather than a magic number? Or possibly even just make the respective > clocks optional, if this is something which would be done per-SoC rather > than per-board? > >From what I know from downstream vendor device trees, these are per board, not for the SoC as a whole. There are I2S/TDM controllers on the SoC which I think are hardwired to certain other IP blocks, such as I2S0 being connected to HDMI, but I2S1 can be routed outside of the SoC where these come into play I believe. As for making them boolean properties, I'd rather not. If I were to make it two mutually exclusive booleans, this would result in 4 possible states rather than 3, and require complexity to check it both in the schema and in the probe function. Like this, I can get away with a switch case that has a fallthrough, and a list of consts in the schema. > > + > > + "#sound-dai-cells": > > + const: 0 > > + > > + rockchip,no-dmaengine: > > + description: > > + If present, driver will not register a pcm dmaengine, only the dai. > > + If the dai is part of multi-dais, the property should be present. > > + type: boolean > > That sounds a lot more like a policy decision specific to the Linux > driver implementation, than something which really belongs in DT as a > description of the platform. I agree. Should I be refactoring this into a module parameter or something along those lines? I'm unsure of where this goes. > > > + > > + rockchip,playback-only: > > + description: Specify that the controller only has playback > > capability. > > + type: boolean > > + > > + rockchip,capture-only: > > + description: Specify that the controller only has capture capability. > > + type: boolean > > Could those be inferred from the compatible string, or are there cases > where you have multiple instances of the IP block in different > configurations within the same SoC? (Or if it's merely reflecting > whether the respective interface is actually wired up externally, could > that be inferred from the attached codec?) > > Robin. > They can't be inferred from the SoC because there are indeed multiple instances of this IP block in different configurations on the same SoC. The RK3566 and RK3568 have four in total, of two different categories, each being able to be configured for a different format (though the number of channels and available formats vary for the two categories, one group only supports I2S and PCM with two channels) The particular configuration may even vary per-board; an I2S/TDM controller may be connected to an external codec which does not support capture, whereas on another board it may be connected to one that does. As an example, if I understand it correctly, I2S3 on the RK3566 and RK3568 can do 2 channels RX and TX in I2S mode, but only 2 channels either RX or TX in PCM mode, but I'm unsure of the language in the (still not public) documentation I have. Regards, Nicolas Frattaroli