All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Kevin Hilman <khilman@baylibre.com>
Cc: devicetree@vger.kernel.org, ulf.hansson@linaro.org,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Juri Lelli <Juri.Lelli@arm.com>,
	linux-pm@vger.kernel.org, sboyd@codeaurora.org,
	linux-arm-msm@vger.kernel.org, rjw@rjwysocki.net,
	Axel Haslam <ahaslam+renesas@baylibre.com>,
	Marc Titinger <mtitinger+renesas@baylibre.com>,
	Brendan Jackman <Brendan.Jackman@arm.com>,
	Lina Iyer <lina.iyer@linaro.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	andy.gross@linaro.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
Date: Wed, 24 Aug 2016 15:07:38 +0100	[thread overview]
Message-ID: <9b2ed5d3-c071-8828-5a22-1ab6f3753d74@arm.com> (raw)
In-Reply-To: <m2fuq0k4tj.fsf@baylibre.com>



On 19/08/16 19:10, Kevin Hilman wrote:
> Sudeep Holla <sudeep.holla@arm.com> writes:
>
> [...]
>
>> In general whatever binding we come up must not just address OS
>> coordinated mode. Also I was thinking to have better coverage in the
>> description by having a bit more complex system like:
>>
>> cluster0
>> 	CLUSTER_RET(Retention)
>> 	CLUSTER_PG(Power Gate)
>> 	core0
>> 		CORE_RET
>> 		CORE_PG
>> 	core1
>> 		CORE_RET
>> 		CORE_PG
>
> Also, remember that a power domain may contain more than just CPUs, so
> this will also need to handle things like:
>
> 	device0..N
>         	DEV_CLK_GATE
>                 DEV_RET
>                 DEV_PG
>
> So, as (I think) Lina was trying to say, including CPU idle states
> inside domain idles states doesn't really scale well because it would
> also imply domain states would also include device idle states.
>
> IMO, the device-specific states belong in the device nodes, and that
> includes CPUs.
>

OK, IIUC we don't have device idle states binding today, so we are not
breaking anything there. Can you elaborate on the issue you see if we
just have domain idle-states ? Is it because we currently create genpd
domain for each entry ?

If a CPU/Device can be enter idle-state(s) it means that it is in a
power domain on its own, so I don't see any issue in such representation.

> It's up to the domain (genpd) governor to look at *all* devices in the
> domain, check their state and make a domain-wide decision.
>

Lets not mix the current genpd implementation in the kernel into this
discussion for simplicity. How is the implementation in the kernel today
and what can be done is a separate topic.

What this discussion should aim at is to present the idle states in the
system in the device tree so that it address the issues we have
currently and extensible in near future with any compatibility issues.

> The tricky part remains, IMO, the mapping between device/CPU states and
> allowable domain states.
>
> As was suggested earlier, a good potential starting point would be that
> all devices/CPUs would need to be in their deepest state before the
> domain would make any decisions.  While that leaves soem power savings
> on the table, it maps well to how genpd works today with only on/off
> states and could be extended with more complicated governors down the
> road.
>

Agreed.

Some example below for discussion, feel free to add more cases.

--
Regards,
Sudeep


--->8

1. Dual cluster with 2 CPUs in each cluster with powerdown at both CPU and
    cluster level

   idle-states {
     CPU_SLEEP_0: cpu-sleep-0 {
       ...
       entry-latency-us = <300>;
       ...
     };
     CLUSTER_SLEEP_0: cluster-sleep-0 {
       ...
       entry-latency-us = <300>;
       ...
     };
   };

   cpu@0 {
     ...
     /*
      * implentation may ignore cpu-idle-states if power-domains
      * has idle-states, DT's may have both for backward compatibility
      */
     cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
     power-domains = <&CPU_0_1_PD>;
     ...
   };

   cpu@1 {
     ...
     cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
     power-domains = <&CPU_0_1_PD>;
     ...
   };

   cpu@100 {
     ...
     cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
     power-domains = <&CPU_1_0_PD>;
     ...
   };

   cpu@101 {
     ...
     cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
     power-domains = <&CPU_1_1_PD>;
     ...
   };

   power-domains {
     CLUSTER_0_PD: cluster-0-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0>;
     };
     CPU_0_0_PD: cpu-0-0-pd@0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0>;
       power-domains = <&CLUSTER_0_PD>;
     };
     CPU_0_1_PD: cpu-0-1-pd@1 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0>;
       power-domains = <&CLUSTER_0_PD>;
     };
     CLUSTER_1_PD: cluster-1-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0>;
     };
     CPU_1_0_PD: cpu-1-0-pd@0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0>;
       power-domains = <&CLUSTER_1_PD>;
     };
     CPU_1_1_PD: cpu-1-1-pd@1 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0>;
       power-domains = <&CLUSTER_1_PD>;
     };
   };

2. Dual cluster with 2 CPUs in each cluster with retention and powerdown 
at both
    CPU and cluster level

   idle-states {
     CPU_SLEEP_0: cpu-sleep-0 { /* Retention */
       ...
       entry-latency-us = <100>;
       ...
     };
     CPU_SLEEP_1: cpu-sleep-1 { /* Power-down */
       ...
       entry-latency-us = <500>;
       ...
     };
     CLUSTER_SLEEP_0: cluster-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     CLUSTER_SLEEP_1: cluster-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
   };

   cpu@0 {
     ...
     power-domains = <&CPU_0_1_PD>;
     ...
   };

   cpu@1 {
     ...
     power-domains = <&CPU_0_1_PD>;
     ...
   };

   cpu@100 {
     ...
     power-domains = <&CPU_1_0_PD>;
     ...
   };

   cpu@101 {
     ...
     power-domains = <&CPU_1_1_PD>;
     ...
   };

   power-domains {
     /*
      * Each cluster/core PD may point to different idle states,
      * it's all same here in the example to keep it short and
      * simple
      */
     CLUSTER_0_PD: cluster-0-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
     };
     CPU_0_0_PD: cpu-0-0-pd@0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
       power-domains = <&CLUSTER_0_PD>;
     };
     CPU_0_1_PD: cpu-0-1-pd@1 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
       power-domains = <&CLUSTER_0_PD>;
     };
     CLUSTER_1_PD: cluster-1-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
     };
     CPU_1_0_PD: cpu-1-0-pd@0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
       power-domains = <&CLUSTER_1_PD>;
     };
     CPU_1_1_PD: cpu-1-1-pd@1 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
       power-domains = <&CLUSTER_1_PD>;
     };
   };

3. Dual cluster with 2 CPUs in each cluster with retention and powerdown at
    just cluster level

   idle-states {
     CLUSTER_SLEEP_0: cluster-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     CLUSTER_SLEEP_1: cluster-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
   };

   cpu@0 {
     ...
     power-domains = <&CLUSTER_0_PD>;
     ...
   };

   cpu@1 {
     ...
     power-domains = <&CLUSTER_0_PD>;
     ...
   };

   cpu@100 {
     ...
     power-domains = <&CLUSTER_1_PD>;
     ...
   };

   cpu@101 {
     ...
     power-domains = <&CLUSTER_1_PD>;
     ...
   };

   power-domains {
     CLUSTER_0_PD: cluster-0-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
     };
     CLUSTER_1_PD: cluster-1-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
     };
   };

4. 4 devices sharing the power domain.

   idle-states {
     /*
      * Device idle states may differ from CPU idle states in terms
      * of the list of properties
      */
     DEVPD_SLEEP_0: devpd-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     DEVPD_SLEEP_1: devpd-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
   };

   dev@0 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev@1 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev@2 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev@3 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   power-domains {
     DEV_PD_0: device-pd-0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&DEVPD_SLEEP_0 &DEVPD_SLEEP_1>;
     };
   };

5. 4 devices sharing the power domain + another device sharing the power
    domain but has it's own sub-domain

   idle-states {
     DEVPD_0_SLEEP_0: devpd-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     DEVPD_0_SLEEP_1: devpd-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
     DEVPD_1_SLEEP_0: devpd-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     DEVPD_1_SLEEP_1: devpd-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
   };

   dev@0 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev@1 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev@2 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev@3 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev@4 {
     ...
     power-domains = <&DEV_PD_1>;
     ...
   };

   power-domains {
     DEV_PD_0: device-pd-0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&DEVPD_0_SLEEP_0 &DEVPD_0_SLEEP_1>;
     };
     DEV_PD_1: device-pd-1 {
       #power-domain-cells = <0>;
       power-domains = <&DEV_PD_0>;
       domain-idle-states = <&DEVPD_1_SLEEP_0 &DEVPD_1_SLEEP_1>;
     };
   };

WARNING: multiple messages have this Message-ID (diff)
From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
Date: Wed, 24 Aug 2016 15:07:38 +0100	[thread overview]
Message-ID: <9b2ed5d3-c071-8828-5a22-1ab6f3753d74@arm.com> (raw)
In-Reply-To: <m2fuq0k4tj.fsf@baylibre.com>



On 19/08/16 19:10, Kevin Hilman wrote:
> Sudeep Holla <sudeep.holla@arm.com> writes:
>
> [...]
>
>> In general whatever binding we come up must not just address OS
>> coordinated mode. Also I was thinking to have better coverage in the
>> description by having a bit more complex system like:
>>
>> cluster0
>> 	CLUSTER_RET(Retention)
>> 	CLUSTER_PG(Power Gate)
>> 	core0
>> 		CORE_RET
>> 		CORE_PG
>> 	core1
>> 		CORE_RET
>> 		CORE_PG
>
> Also, remember that a power domain may contain more than just CPUs, so
> this will also need to handle things like:
>
> 	device0..N
>         	DEV_CLK_GATE
>                 DEV_RET
>                 DEV_PG
>
> So, as (I think) Lina was trying to say, including CPU idle states
> inside domain idles states doesn't really scale well because it would
> also imply domain states would also include device idle states.
>
> IMO, the device-specific states belong in the device nodes, and that
> includes CPUs.
>

OK, IIUC we don't have device idle states binding today, so we are not
breaking anything there. Can you elaborate on the issue you see if we
just have domain idle-states ? Is it because we currently create genpd
domain for each entry ?

If a CPU/Device can be enter idle-state(s) it means that it is in a
power domain on its own, so I don't see any issue in such representation.

> It's up to the domain (genpd) governor to look at *all* devices in the
> domain, check their state and make a domain-wide decision.
>

Lets not mix the current genpd implementation in the kernel into this
discussion for simplicity. How is the implementation in the kernel today
and what can be done is a separate topic.

What this discussion should aim at is to present the idle states in the
system in the device tree so that it address the issues we have
currently and extensible in near future with any compatibility issues.

> The tricky part remains, IMO, the mapping between device/CPU states and
> allowable domain states.
>
> As was suggested earlier, a good potential starting point would be that
> all devices/CPUs would need to be in their deepest state before the
> domain would make any decisions.  While that leaves soem power savings
> on the table, it maps well to how genpd works today with only on/off
> states and could be extended with more complicated governors down the
> road.
>

Agreed.

Some example below for discussion, feel free to add more cases.

--
Regards,
Sudeep


--->8

1. Dual cluster with 2 CPUs in each cluster with powerdown at both CPU and
    cluster level

   idle-states {
     CPU_SLEEP_0: cpu-sleep-0 {
       ...
       entry-latency-us = <300>;
       ...
     };
     CLUSTER_SLEEP_0: cluster-sleep-0 {
       ...
       entry-latency-us = <300>;
       ...
     };
   };

   cpu at 0 {
     ...
     /*
      * implentation may ignore cpu-idle-states if power-domains
      * has idle-states, DT's may have both for backward compatibility
      */
     cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
     power-domains = <&CPU_0_1_PD>;
     ...
   };

   cpu at 1 {
     ...
     cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
     power-domains = <&CPU_0_1_PD>;
     ...
   };

   cpu at 100 {
     ...
     cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
     power-domains = <&CPU_1_0_PD>;
     ...
   };

   cpu at 101 {
     ...
     cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
     power-domains = <&CPU_1_1_PD>;
     ...
   };

   power-domains {
     CLUSTER_0_PD: cluster-0-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0>;
     };
     CPU_0_0_PD: cpu-0-0-pd at 0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0>;
       power-domains = <&CLUSTER_0_PD>;
     };
     CPU_0_1_PD: cpu-0-1-pd at 1 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0>;
       power-domains = <&CLUSTER_0_PD>;
     };
     CLUSTER_1_PD: cluster-1-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0>;
     };
     CPU_1_0_PD: cpu-1-0-pd at 0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0>;
       power-domains = <&CLUSTER_1_PD>;
     };
     CPU_1_1_PD: cpu-1-1-pd at 1 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0>;
       power-domains = <&CLUSTER_1_PD>;
     };
   };

2. Dual cluster with 2 CPUs in each cluster with retention and powerdown 
at both
    CPU and cluster level

   idle-states {
     CPU_SLEEP_0: cpu-sleep-0 { /* Retention */
       ...
       entry-latency-us = <100>;
       ...
     };
     CPU_SLEEP_1: cpu-sleep-1 { /* Power-down */
       ...
       entry-latency-us = <500>;
       ...
     };
     CLUSTER_SLEEP_0: cluster-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     CLUSTER_SLEEP_1: cluster-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
   };

   cpu at 0 {
     ...
     power-domains = <&CPU_0_1_PD>;
     ...
   };

   cpu at 1 {
     ...
     power-domains = <&CPU_0_1_PD>;
     ...
   };

   cpu at 100 {
     ...
     power-domains = <&CPU_1_0_PD>;
     ...
   };

   cpu at 101 {
     ...
     power-domains = <&CPU_1_1_PD>;
     ...
   };

   power-domains {
     /*
      * Each cluster/core PD may point to different idle states,
      * it's all same here in the example to keep it short and
      * simple
      */
     CLUSTER_0_PD: cluster-0-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
     };
     CPU_0_0_PD: cpu-0-0-pd at 0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
       power-domains = <&CLUSTER_0_PD>;
     };
     CPU_0_1_PD: cpu-0-1-pd at 1 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
       power-domains = <&CLUSTER_0_PD>;
     };
     CLUSTER_1_PD: cluster-1-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
     };
     CPU_1_0_PD: cpu-1-0-pd at 0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
       power-domains = <&CLUSTER_1_PD>;
     };
     CPU_1_1_PD: cpu-1-1-pd at 1 {
       #power-domain-cells = <0>;
       domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
       power-domains = <&CLUSTER_1_PD>;
     };
   };

3. Dual cluster with 2 CPUs in each cluster with retention and powerdown at
    just cluster level

   idle-states {
     CLUSTER_SLEEP_0: cluster-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     CLUSTER_SLEEP_1: cluster-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
   };

   cpu at 0 {
     ...
     power-domains = <&CLUSTER_0_PD>;
     ...
   };

   cpu at 1 {
     ...
     power-domains = <&CLUSTER_0_PD>;
     ...
   };

   cpu at 100 {
     ...
     power-domains = <&CLUSTER_1_PD>;
     ...
   };

   cpu at 101 {
     ...
     power-domains = <&CLUSTER_1_PD>;
     ...
   };

   power-domains {
     CLUSTER_0_PD: cluster-0-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
     };
     CLUSTER_1_PD: cluster-1-pd {
       #power-domain-cells = <0>;
       domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
     };
   };

4. 4 devices sharing the power domain.

   idle-states {
     /*
      * Device idle states may differ from CPU idle states in terms
      * of the list of properties
      */
     DEVPD_SLEEP_0: devpd-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     DEVPD_SLEEP_1: devpd-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
   };

   dev at 0 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev at 1 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev at 2 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev at 3 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   power-domains {
     DEV_PD_0: device-pd-0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&DEVPD_SLEEP_0 &DEVPD_SLEEP_1>;
     };
   };

5. 4 devices sharing the power domain + another device sharing the power
    domain but has it's own sub-domain

   idle-states {
     DEVPD_0_SLEEP_0: devpd-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     DEVPD_0_SLEEP_1: devpd-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
     DEVPD_1_SLEEP_0: devpd-sleep-0 { /* Retention */
       ...
       entry-latency-us = <300>;
       ...
     };
     DEVPD_1_SLEEP_1: devpd-sleep-1 {/* Power-down */
       ...
       entry-latency-us = <1000>;
       ...
     };
   };

   dev at 0 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev at 1 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev at 2 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev at 3 {
     ...
     power-domains = <&DEV_PD_0>;
     ...
   };

   dev at 4 {
     ...
     power-domains = <&DEV_PD_1>;
     ...
   };

   power-domains {
     DEV_PD_0: device-pd-0 {
       #power-domain-cells = <0>;
       domain-idle-states = <&DEVPD_0_SLEEP_0 &DEVPD_0_SLEEP_1>;
     };
     DEV_PD_1: device-pd-1 {
       #power-domain-cells = <0>;
       power-domains = <&DEV_PD_0>;
       domain-idle-states = <&DEVPD_1_SLEEP_0 &DEVPD_1_SLEEP_1>;
     };
   };

  reply	other threads:[~2016-08-24 14:07 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-04 23:04 [PATCH v3 00/15] PM: SoC idle support using PM domains Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 01/15] PM / Domains: Allow domain power states to be read from DT Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-09 23:55   ` Rob Herring
2016-08-09 23:55     ` Rob Herring
2016-08-10 15:14   ` Sudeep Holla
2016-08-10 15:14     ` Sudeep Holla
2016-08-10 16:40     ` Lina Iyer
2016-08-10 16:40       ` Lina Iyer
     [not found]       ` <20160810164034.GA1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-10 18:09         ` Sudeep Holla
2016-08-10 18:09           ` Sudeep Holla
2016-08-10 18:13           ` Sudeep Holla
2016-08-10 18:13             ` Sudeep Holla
     [not found]           ` <5e59874c-bbb7-270a-199c-da1ff5932554-5wv7dgnIgG8@public.gmane.org>
2016-08-11 21:10             ` Lina Iyer
2016-08-11 21:10               ` Lina Iyer
     [not found]               ` <20160811211023.GC1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-12  9:47                 ` Brendan Jackman
2016-08-12  9:47                   ` Brendan Jackman
2016-08-12 10:08               ` Sudeep Holla
2016-08-12 10:08                 ` Sudeep Holla
2016-08-15 16:08                 ` Lina Iyer
2016-08-15 16:08                   ` Lina Iyer
2016-08-15 16:14                   ` Sudeep Holla
2016-08-15 16:14                     ` Sudeep Holla
2016-08-15 22:40                     ` Lina Iyer
2016-08-15 22:40                       ` Lina Iyer
     [not found]                       ` <20160815224014.GF1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-16  8:34                         ` Brendan Jackman
2016-08-16  8:34                           ` Brendan Jackman
2016-08-16  8:41                       ` Brendan Jackman
2016-08-16  8:41                         ` Brendan Jackman
2016-08-16  9:19                         ` Sudeep Holla
2016-08-16  9:19                           ` Sudeep Holla
2016-08-12 12:35               ` Brendan Jackman
2016-08-12 12:35                 ` Brendan Jackman
2016-08-15 16:06                 ` Lina Iyer
2016-08-15 16:06                   ` Lina Iyer
2016-08-19 18:10           ` Kevin Hilman
2016-08-19 18:10             ` Kevin Hilman
2016-08-24 14:07             ` Sudeep Holla [this message]
2016-08-24 14:07               ` Sudeep Holla
     [not found]   ` <1470351902-43103-3-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-24 13:48     ` [RFC 0/6] Illustration of using domain-idle-states for CPU " Brendan Jackman
2016-08-24 13:48       ` [RFC 1/6] cpuidle: Rename cpuidle_get_{cpu->dev}_driver Brendan Jackman
2016-08-24 13:48       ` [RFC 2/6] cpuidle: Add public funcion to get driver from CPU index Brendan Jackman
     [not found]       ` <20160824134822.3591-1-brendan.jackman-5wv7dgnIgG8@public.gmane.org>
2016-08-24 13:48         ` [RFC 3/6] cpuidle: Add device_node pointer in cpuidle_state Brendan Jackman
2016-08-24 13:48         ` [RFC 6/6] arm64: dts: Add domain-idle-states for Juno r0 power domains Brendan Jackman
2016-08-24 13:48       ` [RFC 4/6] cpuidle: dt: Add support for reading states from " Brendan Jackman
2016-08-24 13:48       ` [RFC 5/6] arm64: dts: Add Juno r0 CPU power domain tree Brendan Jackman
2016-08-04 23:04 ` [PATCH v3 03/15] PM / Domains: Abstract genpd locking Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 04/15] PM / Domains: Support IRQ safe PM domains Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 05/15] PM / doc: Update device documentation for devices in " Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 06/15] PM / cpu_domains: Setup PM domains for CPUs/clusters Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 07/15] ARM: cpuidle: Add runtime PM support for CPUs Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 08/15] timer: Export next wake up of a CPU Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 09/15] PM / cpu_domains: Add PM Domain governor for CPUs Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 10/15] doc / cpu_domains: Describe CPU PM domains setup and governor Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 11/15] drivers: firmware: psci: Allow OS Initiated suspend mode Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 12/15] drivers: firmware: psci: Support cluster idle states for OS-Initiated Lina Iyer
2016-08-04 23:04   ` Lina Iyer
2016-08-04 23:05 ` [PATCH v3 13/15] dt/bindings: Add PSCI OS-Initiated PM Domains bindings Lina Iyer
2016-08-04 23:05   ` Lina Iyer
2016-08-05 14:44   ` Lina Iyer
2016-08-05 14:44     ` Lina Iyer
2016-08-04 23:05 ` [PATCH v3 14/15] ARM64: dts: Add PSCI cpuidle support for MSM8916 Lina Iyer
2016-08-04 23:05   ` Lina Iyer
     [not found] ` <1470351902-43103-1-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-04 23:05   ` [PATCH v3 15/15] ARM64: dts: Define CPU power domain " Lina Iyer
2016-08-04 23:05     ` Lina Iyer
2016-08-10 15:27     ` Sudeep Holla
2016-08-10 15:27       ` Sudeep Holla
2016-08-10 17:35       ` Lina Iyer
2016-08-10 17:35         ` Lina Iyer
2016-08-11  9:30         ` Sudeep Holla
2016-08-11  9:30           ` Sudeep Holla

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=9b2ed5d3-c071-8828-5a22-1ab6f3753d74@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=Brendan.Jackman@arm.com \
    --cc=Juri.Lelli@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=ahaslam+renesas@baylibre.com \
    --cc=andy.gross@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=khilman@baylibre.com \
    --cc=lina.iyer@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mtitinger+renesas@baylibre.com \
    --cc=rjw@rjwysocki.net \
    --cc=sboyd@codeaurora.org \
    --cc=ulf.hansson@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 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.