devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Sebastian Capella <sebastian.capella@linaro.org>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
	Mike Turquette <mturquette@linaro.org>,
	Tomasz Figa <t.figa@samsung.com>,
	Mark Hambleton <mark.hambleton@broadcom.com>,
	Russell King <linux@arm.linux.org.uk>,
	Nicolas Pitre <nico@linaro.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	Dave P Martin <Dave.Martin@arm.com>,
	Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Kevin Hilman <khilman@linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Kumar Gala <galak@codeaurora.org>,
	Rob Herring <robh+dt@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Antti Miettinen <ananaza@iki.fi>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Amit
Subject: Re: [PATCH RFC v5 3/3] Documentation: arm: define DT idle states bindings
Date: Mon, 7 Apr 2014 12:52:53 +0100	[thread overview]
Message-ID: <20140407115252.GA25563@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <CADHgK6v-t69qLYTcez+m2rE1tRecVsKfgwDdPrNPJOKPbmL-nA@mail.gmail.com>

On Fri, Apr 04, 2014 at 11:01:06PM +0100, Sebastian Capella wrote:
> Hi Lorenzo,
> 
> I like this :)
> 
> I was going to suggest linking the tree upside down (starting with the
> leaves such that walking the list takes you back to the root node
> (system sleep), but I don't think it matters as long as the
> relationship is established (which this does).  I tend to think of
> these states in that order, starting from the leaf(shallowest idle
> state) and working back to the root(system sleep) since it provides a
> simple linear view of the sleep states from the cpu perspective, yet
> keeps the heirarchy.

Copied the bindings here for the sake of this discussion.

I think it is more natural to have deeper states pointing at their
subnodes instead of the other way around. When you are in eg
cluster-sleep-0 below you want to check what subnodes the current
state "contains", not the other way around (eg in cluster-sleep-0, by
checking all subnodes we can span the power-domains and check what needs
saving/restoring).

It would be awkward to be forced to check, for every state, all state
nodes pointing at it, the dependency is better defined in the state
itself.

Furthermore, this approch gets closer to what we will do with ACPI,
where state nodes will become ACPI objects returned by AML methods (which
avoids duplication, as phandles do).

Should I go for this approach and leave the ordering to the DT idle state
nodes flat declaration order ? Or we still want to define a property for
that ?

Please, let me know what you think, thanks.

Lorenzo

idle-states {
       entry-method = "arm,psci-cpu-suspend";

	CPU_RETENTION_0: cpu-retention-0 {
		       compatible = "arm,idle-state";
		       cache-state-retained;
		       entry-method-param = <0x0010000>;
		       entry-latency-us = <20>;
		       exit-latency-us = <40>;
		       min-residency-us = <30>;
		       power-domains = <&pd_cores 0>,
				       <&pd_cores 1>,
				       <&pd_cores 2>,
				       <&pd_cores 3>,
	};

	CPU_SLEEP_0: cpu-sleep-0 {
		       /* cpu sleep */
		       compatible = "arm,idle-state";
		       entry-method-param = <0x0010000>;
		       entry-latency-us = <250>;
		       exit-latency-us = <500>;
		       min-residency-us = <350>;
		       power-domains = <&pd_cores 0>,
				       <&pd_cores 1>,
				       <&pd_cores 2>,
				       <&pd_cores 3>,
	};

	CPU_SLEEP_1: cpu-sleep-1 {
		       /* cpu sleep */
		       compatible = "arm,idle-state";
		       entry-method-param = <0x0010000>;
		       entry-latency-us = <250>;
		       exit-latency-us = <500>;
		       min-residency-us = <350>;
				       <&pd_cores 4>,
				       <&pd_cores 5>,
				       <&pd_cores 6>,
				       <&pd_cores 7>;
	};

	CLUSTER_RETENTION_0: cluster-retention-0 {
	       compatible = "arm,idle-state";
	       logic-state-retained;
	       cache-state-retained;
	       entry-method-param = <0x1010000>;
	       entry-latency-us = <50>;
	       exit-latency-us = <800>;
	       min-residency-us = <2400>;
	       power-domains = <&pd_clusters 0>;
	       substates = <&CPU_SLEEP_0>;
	};

	CLUSTER_SLEEP_0: cluster-sleep-0 {
	       compatible = "arm,idle-state";
	       entry-method-param = <0x1010000>;
	       entry-latency-us = <600>;
	       exit-latency-us = <1100>;
	       min-residency-us = <2700>;
	       power-domains = <&pd_clusters 0>;
	       substates = <&CPU_SLEEP_0>;
	};

	CLUSTER_SLEEP_1: cluster-sleep-1 {
	       compatible = "arm,idle-state";
	       entry-method-param = <0x1010000>;
	       entry-latency-us = <600>;
	       exit-latency-us = <1100>;
	       min-residency-us = <2700>;
	       power-domains = <&pd_clusters 1>;
	       substates = <&CPU_SLEEP_1>;
	};

	SYSTEM_SLEEP_0: system-sleep-0 {
	       compatible = "arm,idle-state";
	       entry-method-param = <0x2010000>;
	       entry-latency-us = <6000>;
	       exit-latency-us = <10000>;
	       min-residency-us = <30000>;
	       power-domains = <&pd_system 0>;
	       substates = <&CLUSTER_SLEEP_0>, <&CLUSTER_SLEEP_1>;
	};
};

  reply	other threads:[~2014-04-07 11:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18 11:28 [PATCH RFC v5 0/3] ARM: defining idle states DT bindings Lorenzo Pieralisi
2014-03-18 11:28 ` [PATCH RFC v5 1/3] Documentation: devicetree: psci: define CPU suspend parameter Lorenzo Pieralisi
2014-03-18 11:28 ` [PATCH RFC v5 2/3] Documentation: arm: add cache DT bindings Lorenzo Pieralisi
2014-03-18 11:28 ` [PATCH RFC v5 3/3] Documentation: arm: define DT idle states bindings Lorenzo Pieralisi
2014-04-04 15:56   ` Lorenzo Pieralisi
2014-04-04 22:01     ` Sebastian Capella
2014-04-07 11:52       ` Lorenzo Pieralisi [this message]
2014-04-07 12:25     ` Vincent Guittot
2014-04-07 14:36       ` Lorenzo Pieralisi
2014-04-07 15:34         ` Vincent Guittot
2014-04-07 18:03           ` Lorenzo Pieralisi
2014-04-08  9:11             ` Vincent Guittot
2014-04-29 10:56   ` Lorenzo Pieralisi

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=20140407115252.GA25563@e102568-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Charles.Garcia-Tobin@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=ananaza@iki.fi \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=khilman@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.hambleton@broadcom.com \
    --cc=mturquette@linaro.org \
    --cc=nico@linaro.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=sebastian.capella@linaro.org \
    --cc=t.figa@samsung.com \
    --cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).