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=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 5C56DC3A5A1 for ; Thu, 22 Aug 2019 12:36:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2E16723402 for ; Thu, 22 Aug 2019 12:36:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566477407; bh=ga6b31QBXofW14aPOhrj0afNHMcSfr0f4f2qhLAjSZY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=jUHjfu/S7BySfuDHZXhVp+Jrd6Svi3DcxPy8sQ6tMKiL7u0Y7D/9fjSGwqfpKxLJP ekghs4KLnoZcEvn9nkDcx3Wd5PPPqseiTeM+RfmzApC2nfrrG8gQvaN/C52lXKOLIf V5TwNIxBitTiNfBr0Gs3K13tKHlL5iDF8YkAoR40= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387755AbfHVMgq (ORCPT ); Thu, 22 Aug 2019 08:36:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:33346 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725856AbfHVMgp (ORCPT ); Thu, 22 Aug 2019 08:36:45 -0400 Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 625422341C; Thu, 22 Aug 2019 12:36:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566477404; bh=ga6b31QBXofW14aPOhrj0afNHMcSfr0f4f2qhLAjSZY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=g2mTxzcL+6XNgmErJ9kMiY3PPEq2ZMtzru9TPrxdGUohnxDtsE67ZneTZy0eck/yq zq1pp4KgfNUEfjwQMBfukukqpXmKK0kpFiXpL5ce206wKBkz0Ni4/t+a2esWyiRcst iUUIKkppW4adHUGQ02tZ0ogfNItNFHsOBVSWDgIA= Received: by mail-qk1-f181.google.com with SMTP id w18so4954359qki.0; Thu, 22 Aug 2019 05:36:44 -0700 (PDT) X-Gm-Message-State: APjAAAXIqfqnJSOQkSL3fECc9671kgvpAZWox0nhWQ+Z00mfTvAIaSb9 7/diQU3llZCuh9JUVYUfThyHQfHKtuzzs8h8kw== X-Google-Smtp-Source: APXvYqw9D+dMZT14AHbYvh+UEVNMDJoszz23u/BEVj7KMPjMnlla91PDTwHFIvTe4a0csE3FYX96NJVL1APNKz9t2Y4= X-Received: by 2002:a37:4941:: with SMTP id w62mr3483805qka.119.1566477403498; Thu, 22 Aug 2019 05:36:43 -0700 (PDT) MIME-Version: 1.0 References: <20190809133407.25918-1-srinivas.kandagatla@linaro.org> <20190809133407.25918-2-srinivas.kandagatla@linaro.org> <20190821214436.GA13936@bogus> <0272eafd-0aa5-f695-64e4-f6ad7157a3a6@linaro.org> In-Reply-To: <0272eafd-0aa5-f695-64e4-f6ad7157a3a6@linaro.org> From: Rob Herring Date: Thu, 22 Aug 2019 07:36:32 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/4] dt-bindings: soundwire: add slave bindings To: Srinivas Kandagatla Cc: Vinod , Mark Brown , Banajit Goswami , Patrick Lai , Pierre-Louis Bossart , devicetree@vger.kernel.org, Liam Girdwood , Linux-ALSA , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 22, 2019 at 5:12 AM Srinivas Kandagatla wrote: > > > > On 21/08/2019 22:44, Rob Herring wrote: > > On Fri, Aug 09, 2019 at 02:34:04PM +0100, Srinivas Kandagatla wrote: > >> This patch adds bindings for Soundwire Slave devices that includes how > >> SoundWire enumeration address and Link ID are used to represented in > >> SoundWire slave device tree nodes. > >> > >> Signed-off-by: Srinivas Kandagatla > >> --- > >> .../devicetree/bindings/soundwire/slave.txt | 51 +++++++++++++++++++ > >> 1 file changed, 51 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/soundwire/slave.txt > > > > Can you convert this to DT schema given it is a common binding. > > > > I will give that a go in next version! > > > What does the host controller look like? You need to define the node > > hierarchy. Bus controller schemas should then include the bus schema. > > See spi-controller.yaml. > > Host controller is always parent of these devices which is represented > in the example. > > In my previous patches, i did put this slave bindings in bus.txt, but > Vinod suggested to move it to slave.txt. > > Are you suggesting to add two yamls here, one for slave and one for bus > Or just document this in one bus bindings? One. Like I said, see spi-controller.yaml. > >> diff --git a/Documentation/devicetree/bindings/soundwire/slave.txt b/Documentation/devicetree/bindings/soundwire/slave.txt > >> new file mode 100644 > >> index 000000000000..201f65d2fafa > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/soundwire/slave.txt > >> @@ -0,0 +1,51 @@ > >> +SoundWire slave device bindings. > >> + > >> +SoundWire is a 2-pin multi-drop interface with data and clock line. > >> +It facilitates development of low cost, efficient, high performance systems. > >> + > >> +SoundWire slave devices: > >> +Every SoundWire controller node can contain zero or more child nodes > >> +representing slave devices on the bus. Every SoundWire slave device is > >> +uniquely determined by the enumeration address containing 5 fields: > >> +SoundWire Version, Instance ID, Manufacturer ID, Part ID > >> +and Class ID for a device. Addition to below required properties, > >> +child nodes can have device specific bindings. > >> + > >> +Required properties: > >> +- compatible: "sdw". > >> + Is the textual representation of SoundWire Enumeration > >> + address along with Link ID. compatible string should contain > >> + SoundWire Link ID, SoundWire Version ID, Instance ID, > >> + Manufacturer ID, Part ID and Class ID in order > >> + represented as above and shall be in lower-case hexadecimal > >> + with leading zeroes. Vaild sizes of these fields are > >> + LinkID is 1 nibble, > >> + Version ID is 1 nibble > >> + Instance ID in 1 nibble > >> + MFD in 4 nibbles > >> + PID in 4 nibbles > >> + CID is 2 nibbles > >> + > >> + Version number '0x1' represents SoundWire 1.0 > >> + Version number '0x2' represents SoundWire 1.1 > > > > This can all be a regex. > > > >> + ex: "sdw0110217201000" represents 0 LinkID, > >> + SoundWire 1.0 version slave with Instance ID 1. > >> + More Information on detail of encoding of these fields can be > >> + found in MIPI Alliance DisCo & SoundWire 1.0 Specifications. > >> + > >> +SoundWire example for Qualcomm's SoundWire controller: > >> + > >> +soundwire@c2d0000 { > >> + compatible = "qcom,soundwire-v1.5.0" > >> + reg = <0x0c2d0000 0x2000>; > >> + > >> + spkr_left:wsa8810-left{ > >> + compatible = "sdw0110217201000"; > >> + ... > >> + }; > >> + > >> + spkr_right:wsa8810-right{ > >> + compatible = "sdw0120217201000"; > > > > The normal way to distinguish instances is with 'reg'. So I think you > > need 'reg' with Instance ID moved there at least. Just guessing, but > > perhaps Link ID, too? And for 2 different classes of device is that > > enough? > > In previous bindings ( https://lists.gt.net/linux/kernel/3403276 ) we > did have instance-id as different property, however Pierre had some good > suggestion to make it align with _ADR encoding as per MIPI DisCo spec. > > Do you still think that we should split the instance id to reg property? Assuming you could have more than 1 of the same device on the bus, then you need some way to distinguish them and the way that's done for DT is unit-address/reg. And compatible strings should be constant for each instance. Rob