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=-6.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS 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 9C2C7C5DF64 for ; Wed, 6 Nov 2019 19:21:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 703252075C for ; Wed, 6 Nov 2019 19:21:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573068069; bh=kt51GLtJRGhpxeArH7PbPGc0NGH1R9MH+9Qgg9Bbl2E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=BEyGkD7KoOHJB9loyeqJ2Vsssh3TiheEH620MW9MUwbGoXf69iNcFEhnZRI6lczz+ r24F0GE7XdGvOyYZjTxYLeYaKULkPl2iCAC1OTR1E/CdSxgWFTlrWizbvyXd/uT90q 9jMCjmZy9OOTp48EX8kHMyPQFiUrc20SkDqKSelM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727422AbfKFTVJ (ORCPT ); Wed, 6 Nov 2019 14:21:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:55470 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726713AbfKFTVJ (ORCPT ); Wed, 6 Nov 2019 14:21:09 -0500 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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 23E4D2075C; Wed, 6 Nov 2019 19:21:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573068068; bh=kt51GLtJRGhpxeArH7PbPGc0NGH1R9MH+9Qgg9Bbl2E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IEAPWRQpe0iBBUsDao1BwZCcAb28KOkc7oYh6GKs2SroYSjzRVbW7TXz2ar0KL9d3 sUnYQrBCCep8Y0basL097DguXypI0HNiAZbSzC4S+d4qPGDr14sHOzYFSytB1ET9y6 OdgizA3YtPO8U5omwD7mj8rkAxMmeITXadRB5Qrg= Received: by mail-qk1-f169.google.com with SMTP id m16so25331958qki.11; Wed, 06 Nov 2019 11:21:08 -0800 (PST) X-Gm-Message-State: APjAAAUmMApYqHhGrHxgINZDJ2HwAvSjwYXCfLEgICffl/G18Lsag116 51UTpt7qPDnYGrbs3nvuSBK6iKfoEFOLJ2/Fqg== X-Google-Smtp-Source: APXvYqx32bwEhx99vHD/kDAS+/S75zvMWBv+yskX8CR2wiE5zYnXor6TRM6cgKz+ApVQJE7zjdsPqEDMXPf0REI1jX8= X-Received: by 2002:a37:4904:: with SMTP id w4mr3368103qka.119.1573068067259; Wed, 06 Nov 2019 11:21:07 -0800 (PST) MIME-Version: 1.0 References: <20191018001849.27205-1-srinivas.kandagatla@linaro.org> <20191018001849.27205-2-srinivas.kandagatla@linaro.org> <20191025204338.GA25892@bogus> <90b2d83b-f2b2-3a5d-4deb-589f4b48b208@linaro.org> <371955d9-ad2d-5ddc-31b4-710729feae42@linaro.org> <7811be04-dfda-5953-110c-bca685fdcaa4@linaro.org> In-Reply-To: From: Rob Herring Date: Wed, 6 Nov 2019 13:20:55 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 01/11] ASoC: dt-bindings: add dt bindings for WCD9340/WCD9341 audio codec To: Srinivas Kandagatla Cc: Mark Brown , Linus Walleij , Lee Jones , Vinod Koul , Linux-ALSA , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , spapothi@codeaurora.org, Banajit Goswami , "open list:GPIO SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Wed, Nov 6, 2019 at 12:09 PM Srinivas Kandagatla wrote: > > > > On 05/11/2019 19:08, Rob Herring wrote: > > On Wed, Oct 30, 2019 at 4:55 AM Srinivas Kandagatla > > wrote: > >> > >> > >> > >> On 29/10/2019 20:47, Rob Herring wrote: > >>> On Mon, Oct 28, 2019 at 7:45 AM Srinivas Kandagatla > >>> wrote: > >>>> > >>>> > >>>> > >>>> On 28/10/2019 12:40, Srinivas Kandagatla wrote: > >>>>> Its Phandle. > >>>>> > >>>>> something like this is okay? > >>>>> > >>>>> slim-ifc-dev: > >>>>> $ref: '/schemas/types.yaml#/definitions/phandle-array' > >>>> > >>>> Sorry this should not be an array, so something like this: > >>>> > >>>> slim-ifc-dev: > >>>> description: SLIMBus Interface device phandle > >>> > >>> You're just spelling out the abbreviated name. I can do that much. > >>> What is 'SLIMBus Interface device'? > >> > >> Each SLIMBus Component contains one Interface Device. Which is > >> responsible for Monitoring and reporting the status of component, Data > >> line to Data pin connection setup for SLIMBus streaming. Interface > >> device is enumerated just like any other slim device. > > > > So a standard set of registers every slimbus device has? In hindsight, > > I would have made reg have 2 entries with both addresses. I guess that > > ship has sailed. > > That will break SLIMBus bindings, Which is expecting one device per > device node. Like I said, that ship has sailed... > > > > It seems strange you would need both "devices" described as separate > > nodes in DT. > > Because they are two different devices on the SLIMBus Component. > > > > >> > >> We already have exactly same bindings for WCD9335 in upstream at: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt?h=v5.4-rc5#n42 > >> > >>> > >>> Is it a standard SLIMBus property? If so, document it in the right > >>> place. If not, then needs a vendor prefix. > >> > >> "SLIMBus Interface Device" itself is documented in SLIMBus Specification. > >> > >> If I remember it correctly You suggested me to move to "slim-ifc-dev" > >> as this is part of SLIMBus Specification. > > > > Probably so. If it is common, then document it in bindings/slimbus/bus.txt. > > > As we are dealing with audio codecs here, it might be that > "slim-ifc-dev" is common across wcd9335 and wcd934x but not all devices > on the SLIMBus Component would need handle to interface device. SLIMbus > can also be used for control buses as well which might not need this. Like you said, it's part of the the spec, so define it somewhere common, not in a device specific binding. > > Then here, 'slim-ifc-dev: true' is sufficient. You can just assume we > > convert bus.txt to schema (or feel free to do that :) ). > > We need phandle to the interface device so that we can program the > streaming parameters for the SLIMBus Component. 'true' just means 'I'm using the property' and have no other constraints. The constraints like type would be defined in the common binding and no need to duplicate here. Rob 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=-6.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 9D43AC5DF63 for ; Wed, 6 Nov 2019 19:25:34 +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 1D88A2067B for ; Wed, 6 Nov 2019 19:25:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="KjZRk1BA"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="IEAPWRQp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D88A2067B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 62A1F165F; Wed, 6 Nov 2019 20:24:42 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 62A1F165F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1573068332; bh=9lHzlOygLMgOK9YMJrpoTsQ9XuEEGwjbGEhe5ZlbwYE=; h=References:In-Reply-To:From:Date:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=KjZRk1BA1u0vTHjDN2FyPykDxOvAIkCJ514567c8OV8qJppPVN1EMC3/YmUuKGeA6 pDYR1O/UW7XlgUvE5ygcRhqTkuQyJ+UrE4lRjLNi2zbfuYYXvtNevJY2YRx+WEiexY eedjX4cmoJOf2uWK/IDZu//GW8IuuCXH758U0we4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id E28ACF803F4; Wed, 6 Nov 2019 20:21:15 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 9B95FF800F3; Wed, 6 Nov 2019 20:21:13 +0100 (CET) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 8FE59F80291 for ; Wed, 6 Nov 2019 20:21:09 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8FE59F80291 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="IEAPWRQp" Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 2804E21848 for ; Wed, 6 Nov 2019 19:21:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573068068; bh=kt51GLtJRGhpxeArH7PbPGc0NGH1R9MH+9Qgg9Bbl2E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IEAPWRQpe0iBBUsDao1BwZCcAb28KOkc7oYh6GKs2SroYSjzRVbW7TXz2ar0KL9d3 sUnYQrBCCep8Y0basL097DguXypI0HNiAZbSzC4S+d4qPGDr14sHOzYFSytB1ET9y6 OdgizA3YtPO8U5omwD7mj8rkAxMmeITXadRB5Qrg= Received: by mail-qk1-f182.google.com with SMTP id m4so25648662qke.9 for ; Wed, 06 Nov 2019 11:21:08 -0800 (PST) X-Gm-Message-State: APjAAAU1NZXcFjWdfsZTzhJeTyWLM6Eu/qdElNkcNaBXDTWvfVKZCMex F22u2IdpEODKdomde9XBmKNb7q4ztEYZZnGjnw== X-Google-Smtp-Source: APXvYqx32bwEhx99vHD/kDAS+/S75zvMWBv+yskX8CR2wiE5zYnXor6TRM6cgKz+ApVQJE7zjdsPqEDMXPf0REI1jX8= X-Received: by 2002:a37:4904:: with SMTP id w4mr3368103qka.119.1573068067259; Wed, 06 Nov 2019 11:21:07 -0800 (PST) MIME-Version: 1.0 References: <20191018001849.27205-1-srinivas.kandagatla@linaro.org> <20191018001849.27205-2-srinivas.kandagatla@linaro.org> <20191025204338.GA25892@bogus> <90b2d83b-f2b2-3a5d-4deb-589f4b48b208@linaro.org> <371955d9-ad2d-5ddc-31b4-710729feae42@linaro.org> <7811be04-dfda-5953-110c-bca685fdcaa4@linaro.org> In-Reply-To: From: Rob Herring Date: Wed, 6 Nov 2019 13:20:55 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Srinivas Kandagatla Cc: devicetree@vger.kernel.org, Linux-ALSA , Banajit Goswami , Vinod Koul , Linus Walleij , "linux-kernel@vger.kernel.org" , "open list:GPIO SUBSYSTEM" , Mark Brown , Lee Jones , spapothi@codeaurora.org Subject: Re: [alsa-devel] [PATCH v2 01/11] ASoC: dt-bindings: add dt bindings for WCD9340/WCD9341 audio codec 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, Nov 6, 2019 at 12:09 PM Srinivas Kandagatla wrote: > > > > On 05/11/2019 19:08, Rob Herring wrote: > > On Wed, Oct 30, 2019 at 4:55 AM Srinivas Kandagatla > > wrote: > >> > >> > >> > >> On 29/10/2019 20:47, Rob Herring wrote: > >>> On Mon, Oct 28, 2019 at 7:45 AM Srinivas Kandagatla > >>> wrote: > >>>> > >>>> > >>>> > >>>> On 28/10/2019 12:40, Srinivas Kandagatla wrote: > >>>>> Its Phandle. > >>>>> > >>>>> something like this is okay? > >>>>> > >>>>> slim-ifc-dev: > >>>>> $ref: '/schemas/types.yaml#/definitions/phandle-array' > >>>> > >>>> Sorry this should not be an array, so something like this: > >>>> > >>>> slim-ifc-dev: > >>>> description: SLIMBus Interface device phandle > >>> > >>> You're just spelling out the abbreviated name. I can do that much. > >>> What is 'SLIMBus Interface device'? > >> > >> Each SLIMBus Component contains one Interface Device. Which is > >> responsible for Monitoring and reporting the status of component, Data > >> line to Data pin connection setup for SLIMBus streaming. Interface > >> device is enumerated just like any other slim device. > > > > So a standard set of registers every slimbus device has? In hindsight, > > I would have made reg have 2 entries with both addresses. I guess that > > ship has sailed. > > That will break SLIMBus bindings, Which is expecting one device per > device node. Like I said, that ship has sailed... > > > > It seems strange you would need both "devices" described as separate > > nodes in DT. > > Because they are two different devices on the SLIMBus Component. > > > > >> > >> We already have exactly same bindings for WCD9335 in upstream at: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt?h=v5.4-rc5#n42 > >> > >>> > >>> Is it a standard SLIMBus property? If so, document it in the right > >>> place. If not, then needs a vendor prefix. > >> > >> "SLIMBus Interface Device" itself is documented in SLIMBus Specification. > >> > >> If I remember it correctly You suggested me to move to "slim-ifc-dev" > >> as this is part of SLIMBus Specification. > > > > Probably so. If it is common, then document it in bindings/slimbus/bus.txt. > > > As we are dealing with audio codecs here, it might be that > "slim-ifc-dev" is common across wcd9335 and wcd934x but not all devices > on the SLIMBus Component would need handle to interface device. SLIMbus > can also be used for control buses as well which might not need this. Like you said, it's part of the the spec, so define it somewhere common, not in a device specific binding. > > Then here, 'slim-ifc-dev: true' is sufficient. You can just assume we > > convert bus.txt to schema (or feel free to do that :) ). > > We need phandle to the interface device so that we can program the > streaming parameters for the SLIMBus Component. 'true' just means 'I'm using the property' and have no other constraints. The constraints like type would be defined in the common binding and no need to duplicate here. Rob _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel