From: Josh Cartwright <joshc@codeaurora.org> To: Stephen Warren <swarren@wwwdotorg.org> Cc: Josh Cartwright <joshc@codeaurora.org>, 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 Subject: Re: [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation Date: Tue, 27 Aug 2013 12:01:20 -0500 [thread overview] Message-ID: <20130827170120.GR4035@joshc.qualcomm.com> (raw) In-Reply-To: <5217DB0C.7000101@wwwdotorg.org> Hey Stephen- Thanks for the comments. On Fri, Aug 23, 2013 at 03:58:36PM -0600, Stephen Warren wrote: > On 08/22/2013 01:59 PM, Josh Cartwright wrote: > > 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? > > It's best to define the whole thing from the start if possible. It's > easier to ensure the whole binding is consistent, and nothing has been > left out. That makes sense. I think I'll go down this route for v3 of this patchset: For #1 above, extend the 'reg' property of a slave node to include the group slave ID's in which the slave is a member. The first 'reg' entry will remain the slave's Unique Slave Identifier (USID) as before. For #2, add additional required 'spmi-mid' property in the controller/master node that describes the 2-bit Master Identifier (MID). For #3, rename the SPMI API's s/controller/master/. The current controller/master terminology difference is confusing and unnecessary. > However, it's probably OK to define a subset binding initially and then > expand it later, as long as some thought it put into how it can be > expanded in a way that is 100% compatible: old DTs will still operate > with new kernels and perhaps even new DTs will still operate with old > kernels. > > That said, if the thought is put in to ensure that's possible, it's > probably just as easy to define the whole binding from the start. That all makes sense. 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: 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? Thanks, Josh -- 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: Tue, 27 Aug 2013 12:01:20 -0500 [thread overview] Message-ID: <20130827170120.GR4035@joshc.qualcomm.com> (raw) In-Reply-To: <5217DB0C.7000101@wwwdotorg.org> Hey Stephen- Thanks for the comments. On Fri, Aug 23, 2013 at 03:58:36PM -0600, Stephen Warren wrote: > On 08/22/2013 01:59 PM, Josh Cartwright wrote: > > 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? > > It's best to define the whole thing from the start if possible. It's > easier to ensure the whole binding is consistent, and nothing has been > left out. That makes sense. I think I'll go down this route for v3 of this patchset: For #1 above, extend the 'reg' property of a slave node to include the group slave ID's in which the slave is a member. The first 'reg' entry will remain the slave's Unique Slave Identifier (USID) as before. For #2, add additional required 'spmi-mid' property in the controller/master node that describes the 2-bit Master Identifier (MID). For #3, rename the SPMI API's s/controller/master/. The current controller/master terminology difference is confusing and unnecessary. > However, it's probably OK to define a subset binding initially and then > expand it later, as long as some thought it put into how it can be > expanded in a way that is 100% compatible: old DTs will still operate > with new kernels and perhaps even new DTs will still operate with old > kernels. > > That said, if the thought is put in to ensure that's possible, it's > probably just as easy to define the whole binding from the start. That all makes sense. 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: 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? Thanks, Josh -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2013-08-27 17:01 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 [this message] 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=20130827170120.GR4035@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 \ /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: linkBe 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.