From patchwork Tue Jul 19 19:14:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Warren X-Patchwork-Id: 9238181 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 53B9660574 for ; Tue, 19 Jul 2016 19:16:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 408E720246 for ; Tue, 19 Jul 2016 19:16:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 34BFB26E81; Tue, 19 Jul 2016 19:16:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B7B3F20246 for ; Tue, 19 Jul 2016 19:16:55 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bPaUM-0006H7-TP; Tue, 19 Jul 2016 19:15:30 +0000 Received: from avon.wwwdotorg.org ([70.85.31.133]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bPaUA-0004o3-RN for linux-arm-kernel@lists.infradead.org; Tue, 19 Jul 2016 19:15:20 +0000 Received: from swarren-lx1.nvidia.com (thunderhill.nvidia.com [216.228.112.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by avon.wwwdotorg.org (Postfix) with ESMTPSA id 1FA631C047D; Tue, 19 Jul 2016 13:14:59 -0600 (MDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99 at avon.wwwdotorg.org From: Stephen Warren To: Thierry Reding , Joseph Lo , Rob Herring Subject: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP Date: Tue, 19 Jul 2016 13:14:41 -0600 Message-Id: <20160719191442.15439-2-swarren@wwwdotorg.org> X-Mailer: git-send-email 2.9.2 In-Reply-To: <20160719191442.15439-1-swarren@wwwdotorg.org> References: <20160719191442.15439-1-swarren@wwwdotorg.org> X-NVConfidentiality: public X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160719_121519_039918_3518DAFD X-CRM114-Status: UNSURE ( 9.65 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Stephen Warren , pdeschrijver@nvidia.com, sivaramn@nvidia.com, MLongnecker@nvidia.com, linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP From: Stephen Warren The BPMP implements some services which must be represented by separate nodes. For example, it can provide access to certain I2C controllers, and the I2C bindings represent each I2C controller as a device tree node. Update the binding to describe how the BPMP supports this. Signed-off-by: Stephen Warren Acked-by: Rob Herring Acked-by: Jon Hunter --- .../bindings/firmware/nvidia,tegra186-bpmp.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt index 9a3864f56955..142d363406f6 100644 --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt @@ -38,6 +38,24 @@ implemented by this node: - .../reset/reset.txt - +The BPMP implements some services which must be represented by separate nodes. +For example, it can provide access to certain I2C controllers, and the I2C +bindings represent each I2C controller as a device tree node. Such nodes should +be nested directly inside the main BPMP node. + +Software can determine whether a child node of the BPMP node represents a device +by checking for a compatible property. Any node with a compatible property +represents a device that can be instantiated. Nodes without a compatible +property may be used to provide configuration information regarding the BPMP +itself, although no such configuration nodes are currently defined by this +binding. + +The BPMP firmware defines no single global name-/numbering-space for such +services. Put another way, the numbering scheme for I2C buses is distinct from +the numbering scheme for any other service the BPMP may provide (e.g. a future +hypothetical SPI bus service). As such, child device nodes will have no reg +property, and the BPMP node will have no #address-cells or #size-cells property. + The shared memory bindings for BPMP ----------------------------------- @@ -78,4 +96,9 @@ bpmp { #clock-cells = <1>; #power-domain-cells = <1>; #reset-cells = <1>; + + bpmp-i2c { + compatible = "..."; + ... + }; };