All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Cartwright <joshc@codeaurora.org>
To: Grant Likely <grant.likely@linaro.org>,
	Rob Herring <rob.herring@calxeda.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Kumar Gala <galak@codeaurora.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org,
	Sagar Dharia <sdharia@codeaurora.org>,
	Gilad Avidov <gavidov@codeaurora.org>,
	Michael Bohan <mbohan@codeaurora.org>,
	devicetree@vger.kernel.org
Subject: [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation
Date: Thu, 22 Aug 2013 14:59:06 -0500	[thread overview]
Message-ID: <e42576b69ef3d4e624fbfa2f32f6f79a931b55d6.1377202730.git.joshc@codeaurora.org> (raw)
In-Reply-To: <cover.1377202730.git.joshc@codeaurora.org>

Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
---
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>;
+		};
+	};
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: joshc@codeaurora.org (Josh Cartwright)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation
Date: Thu, 22 Aug 2013 14:59:06 -0500	[thread overview]
Message-ID: <e42576b69ef3d4e624fbfa2f32f6f79a931b55d6.1377202730.git.joshc@codeaurora.org> (raw)
In-Reply-To: <cover.1377202730.git.joshc@codeaurora.org>

Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
---
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 at .. {
+		compatible = "...";
+		reg = <...>;
+
+		#address-cells = <1>;
+		#size-cells <0>;
+
+		child at 0 {
+			compatible = "...";
+			reg = <0>;
+		};
+
+		child at 7 {
+			compatible = "...";
+			reg = <7>;
+		};
+	};
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  parent reply	other threads:[~2013-08-22 19:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-22 20:18 [PATCH RFC v2 0/3] Add support for the System Power Management Interface (SPMI) Josh Cartwright
2013-08-22 20:18 ` Josh Cartwright
2012-12-10 19:41 ` [PATCH RFC v2 1/5] of: Add empty for_each_available_child_of_node() macro definition Josh Cartwright
2013-08-22 22:57   ` Josh Cartwright
2013-08-09 20:37 ` [PATCH RFC v2 4/5] spmi: Add MSM PMIC Arbiter SPMI controller Josh Cartwright
2013-08-09 20:37   ` Josh Cartwright
2013-08-09 20:37 ` [PATCH RFC v2 5/5] spmi: document the PMIC arbiter SPMI bindings Josh Cartwright
2013-08-09 20:37   ` Josh Cartwright
2013-08-23 21:55   ` Stephen Warren
2013-08-23 21:55     ` Stephen Warren
2013-08-09 20:37 ` [PATCH RFC v2 2/5] spmi: Linux driver framework for SPMI Josh Cartwright
2013-08-09 20:37   ` Josh Cartwright
2013-08-22 23:10   ` Greg Kroah-Hartman
2013-08-22 23:10     ` Greg Kroah-Hartman
2013-08-23 16:06     ` Josh Cartwright
2013-08-23 16:06       ` Josh Cartwright
2013-09-09 15:52       ` Mark Brown
2013-09-09 15:52         ` Mark Brown
2013-09-09 16:56         ` Josh Cartwright
2013-09-09 16:56           ` Josh Cartwright
2013-08-22 19:59 ` Josh Cartwright [this message]
2013-08-22 19:59   ` [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation Josh Cartwright
2013-08-23 21:58   ` Stephen Warren
2013-08-23 21:58     ` Stephen Warren
2013-08-27 17:01     ` Josh Cartwright
2013-08-27 17:01       ` Josh Cartwright
2013-08-27 21:55       ` Stephen Warren
2013-08-27 21:55         ` Stephen Warren
2013-08-28 18:00         ` Josh Cartwright
2013-08-28 18:00           ` Josh Cartwright
2013-08-28 18:32           ` Stephen Warren
2013-08-28 18:32             ` Stephen Warren
2013-10-06  6:11         ` Bjorn Andersson
2013-10-06  6:11           ` Bjorn Andersson
     [not found]           ` <CAJAp7Oi-bPytsLtsppdanOi_p0Y5vfBriGB-B5by7w5Z7SGU-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-07 21:17             ` Josh Cartwright
2013-10-07 21:17               ` Josh Cartwright
2013-10-07 21:17               ` Josh Cartwright

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e42576b69ef3d4e624fbfa2f32f6f79a931b55d6.1377202730.git.joshc@codeaurora.org \
    --to=joshc@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gavidov@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ian.campbell@citrix.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mbohan@codeaurora.org \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=sdharia@codeaurora.org \
    --cc=swarren@wwwdotorg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.