From patchwork Thu Aug 22 19:59:06 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josh Cartwright X-Patchwork-Id: 2848442 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 2098C9F2F6 for ; Thu, 22 Aug 2013 22:58:03 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 39A57203FD for ; Thu, 22 Aug 2013 22:58:02 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3190E203F1 for ; Thu, 22 Aug 2013 22:58:01 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VCdp4-0000vr-7K; Thu, 22 Aug 2013 22:57:46 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VCdp0-0004QC-4P; Thu, 22 Aug 2013 22:57:42 +0000 Received: from smtp.codeaurora.org ([198.145.11.231]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VCdoj-0004NG-TA for linux-arm-kernel@lists.infradead.org; Thu, 22 Aug 2013 22:57:29 +0000 Received: from smtp.codeaurora.org (localhost [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 81B1113EE54; Thu, 22 Aug 2013 22:57:03 +0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 486) id 6AD4F13EF9E; Thu, 22 Aug 2013 22:57:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from joshc.qualcomm.com (rrcs-67-52-129-61.west.biz.rr.com [67.52.129.61]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joshc@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id DB32E13F281; Thu, 22 Aug 2013 22:57:02 +0000 (UTC) Received: by joshc.qualcomm.com (Postfix, from userid 1000) id 645C360CA1; Thu, 22 Aug 2013 17:56:44 -0500 (CDT) Message-Id: In-Reply-To: References: From: Josh Cartwright Date: Thu, 22 Aug 2013 14:59:06 -0500 To: Grant Likely , Rob Herring , Greg Kroah-Hartman , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell , Kumar Gala Subject: [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation X-Virus-Scanned: ClamAV using ClamSMTP X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130822_185726_312087_168C41D2 X-CRM114-Status: GOOD ( 17.38 ) X-Spam-Score: -4.7 (----) Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, Gilad Avidov , linux-kernel@vger.kernel.org, Michael Bohan , Sagar Dharia , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Signed-off-by: Josh Cartwright --- I'm introducing this as an RFC, because there are set of assumptions made in this binding spec, that currently hold true for the supported controller/addressing scheme for the Snapdragon 800 series, but don't necessarily hold true for SPMI in general. 1. No use of Group Slave Identifiers (GSIDs) (SPMI allows for a slave to belong to zero or more groups specified by GSID, however this feature isn't currently implemented) 2. No specification of Master Identifier (MID) (A "system integrator" allocates to each master a 2-bit MID, this currently isn't being specified, as it isn't needed by software for the PMIC Arb; not sure if this is of use to other SPMI controllers) 3. Single SPMI master per controller Effectively, only a subset of possible SPMI configurations are specified in this document. So, if it's considered necessary to provide a generic SPMI binding specification, is it acceptable to only define a subset at this time, expanding only when necessary, or shall I expand the definition to at least address 1 & 2, even though they are of no use in the current implementation? Documentation/devicetree/bindings/spmi/spmi.txt | 36 +++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/devicetree/bindings/spmi/spmi.txt diff --git a/Documentation/devicetree/bindings/spmi/spmi.txt b/Documentation/devicetree/bindings/spmi/spmi.txt new file mode 100644 index 0000000..a01b064 --- /dev/null +++ b/Documentation/devicetree/bindings/spmi/spmi.txt @@ -0,0 +1,36 @@ +System Power Management Interface (SPMI) Controller + +This document defines a generic set of bindings for use by SPMI controllers. A +controller is modelled in device tree as a node with zero or more child nodes, +each representing a unique slave on the bus. + +Required properties: +- #address-cells : must be set to 1 +- #size-cells : must be set to 0 + +Child nodes: + +An SPMI controller node can contain zero or more children. Each child must +have a reg property defining its 4-bit Unique Slave Identifier (USID) on the +SPMI bus. This is the ID that has been "statically assigned by the system +integrator", as per the SPMI spec. + +Each child node represents a slave device on the bus. + + controller@.. { + compatible = "..."; + reg = <...>; + + #address-cells = <1>; + #size-cells <0>; + + child@0 { + compatible = "..."; + reg = <0>; + }; + + child@7 { + compatible = "..."; + reg = <7>; + }; + };