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: 650383 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3rv8r54tHQz9ssP for ; Wed, 20 Jul 2016 05:15:01 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751605AbcGSTPA (ORCPT ); Tue, 19 Jul 2016 15:15:00 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:58768 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751451AbcGSTO7 (ORCPT ); Tue, 19 Jul 2016 15:14:59 -0400 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 Cc: linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Mark Rutland , MLongnecker@nvidia.com, sivaramn@nvidia.com, pdeschrijver@nvidia.com, Stephen Warren 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 Sender: linux-tegra-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org 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 = "..."; + ... + }; };