All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Cartwright <joshc@codeaurora.org>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: 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>,
	Ian Campbell <ian.campbell@citrix.com>,
	Kumar Gala <galak@codeaurora.org>,
	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, Wolfram Sang <wsa@the-dreams.de>
Subject: Re: [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation
Date: Wed, 28 Aug 2013 13:00:25 -0500	[thread overview]
Message-ID: <20130828180025.GA808@joshc.qualcomm.com> (raw)
In-Reply-To: <521D2047.8030300@wwwdotorg.org>

On Tue, Aug 27, 2013 at 03:55:19PM -0600, Stephen Warren wrote:
> On 08/27/2013 11:01 AM, Josh Cartwright wrote:
> ...
> > If we want to ensure for the generic bindings that we are fulling
> > characterizing/describing the SPMI bus, then we'll additionally need to
> > tackle an additional identified assumption:
> >
> >   4. One master per SPMI bus.  (The SPMI spec allows for up to 4
> >      masters)
> >
> > On the Snapdragon 800 series, there exists only one software-controlled
> > master, but it is conceivably possible to have a setup with two
> > software-controlled masters on the same SPMI bus.
> >
> > This necessarily means that the description of the slaves and the
> > masters will need to be decoupled; I'm imagining a generic binding
> > supporting multiple masters would look something like this:
>
> Is there a need to represent the other masters in the DT? Sure they're
> there in HW, but if there's no specific way for the
> CPU-to-which-the-DT-applies to actually interact with those other
> masters (except perhaps by experiencing some arbitration delays) then
> presumably there's no need to represent the other masters in DT?

My example is contrived, but there is nothing in the SPMI spec
preventing two masters from being controllable by the same
CPU-to-which-the-DT-applies, sharing the same underlying bus.

I would also expect this configuration to be uncommon, I'm checking with
some folks with more SPMI experience to make sure they agree.

Interestingly, i2c as far as I can tell has also made the same
assumption.  There doesn't appear to be any way to express a
multi-master i2c setup where both masters are controlled by the same OS.

> > 	master0: master@0 {
> > 		compatible = "...";
> > 		#spmi-master-cells = <0>;
> > 		spmi-mid = <0>;
> > 
> > 		...
> > 	};
> > 
> > 	master2: master@2 {
> > 		compatible = "...";
> > 		#spmi-master-cells = <0>;
> > 		spmi-mid = <2>;
> > 
> > 		...
> > 	};
> > 
> > 	spmi_bus {
> > 		compatible = "...";
> > 
> > 		spmi-masters = <&master0 &master2>;
> > 
> > 		foo@0 {
> > 			compatible = "...";
> > 			reg = <0 ...>;
> > 		};
> > 
> > 		foo@8 {
> > 			compatible = "...";
> > 			reg = <8 ...>;
> > 		};
> > 	};
> > 
> > (This will also necessitate a change in the underlying SPMI driver
> > model, in the current implementation, a SPMI master 'owns' a particular
> > device.  This is not a valid assumption to make.)
> > 
> > Would this property-containing-phandle-vector be considered the
> > canonical way of representing nodes with multiple parents in the device
> > tree?
> 
> I don't think I've seen anything like this before, although that
> in-and-of-itself doesn't make it wrong.
> 
> Another approach might be to encode master-vs-slave into a cell in the
> reg property? Something like:
> 
> cell 0 - address type (0: master, 1: unique ID, 2: group ID, ...)
> cell 1 - address value
> 
> I haven't thought much about that; perhaps there are disadvantages doing
> that.

-- 
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: Wed, 28 Aug 2013 13:00:25 -0500	[thread overview]
Message-ID: <20130828180025.GA808@joshc.qualcomm.com> (raw)
In-Reply-To: <521D2047.8030300@wwwdotorg.org>

On Tue, Aug 27, 2013 at 03:55:19PM -0600, Stephen Warren wrote:
> On 08/27/2013 11:01 AM, Josh Cartwright wrote:
> ...
> > If we want to ensure for the generic bindings that we are fulling
> > characterizing/describing the SPMI bus, then we'll additionally need to
> > tackle an additional identified assumption:
> >
> >   4. One master per SPMI bus.  (The SPMI spec allows for up to 4
> >      masters)
> >
> > On the Snapdragon 800 series, there exists only one software-controlled
> > master, but it is conceivably possible to have a setup with two
> > software-controlled masters on the same SPMI bus.
> >
> > This necessarily means that the description of the slaves and the
> > masters will need to be decoupled; I'm imagining a generic binding
> > supporting multiple masters would look something like this:
>
> Is there a need to represent the other masters in the DT? Sure they're
> there in HW, but if there's no specific way for the
> CPU-to-which-the-DT-applies to actually interact with those other
> masters (except perhaps by experiencing some arbitration delays) then
> presumably there's no need to represent the other masters in DT?

My example is contrived, but there is nothing in the SPMI spec
preventing two masters from being controllable by the same
CPU-to-which-the-DT-applies, sharing the same underlying bus.

I would also expect this configuration to be uncommon, I'm checking with
some folks with more SPMI experience to make sure they agree.

Interestingly, i2c as far as I can tell has also made the same
assumption.  There doesn't appear to be any way to express a
multi-master i2c setup where both masters are controlled by the same OS.

> > 	master0: master at 0 {
> > 		compatible = "...";
> > 		#spmi-master-cells = <0>;
> > 		spmi-mid = <0>;
> > 
> > 		...
> > 	};
> > 
> > 	master2: master at 2 {
> > 		compatible = "...";
> > 		#spmi-master-cells = <0>;
> > 		spmi-mid = <2>;
> > 
> > 		...
> > 	};
> > 
> > 	spmi_bus {
> > 		compatible = "...";
> > 
> > 		spmi-masters = <&master0 &master2>;
> > 
> > 		foo at 0 {
> > 			compatible = "...";
> > 			reg = <0 ...>;
> > 		};
> > 
> > 		foo at 8 {
> > 			compatible = "...";
> > 			reg = <8 ...>;
> > 		};
> > 	};
> > 
> > (This will also necessitate a change in the underlying SPMI driver
> > model, in the current implementation, a SPMI master 'owns' a particular
> > device.  This is not a valid assumption to make.)
> > 
> > Would this property-containing-phandle-vector be considered the
> > canonical way of representing nodes with multiple parents in the device
> > tree?
> 
> I don't think I've seen anything like this before, although that
> in-and-of-itself doesn't make it wrong.
> 
> Another approach might be to encode master-vs-slave into a cell in the
> reg property? Something like:
> 
> cell 0 - address type (0: master, 1: unique ID, 2: group ID, ...)
> cell 1 - address value
> 
> I haven't thought much about that; perhaps there are disadvantages doing
> that.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2013-08-28 18:00 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 ` [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation Josh Cartwright
2013-08-22 19:59   ` 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 [this message]
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=20130828180025.GA808@joshc.qualcomm.com \
    --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 \
    --cc=wsa@the-dreams.de \
    /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.