[1/2] PM / Domains: Define DT bindings for PM QoS device latencies

Message ID 1459432226-22562-1-git-send-email-ulf.hansson@linaro.org
State New
Headers show

Commit Message

Ulf Hansson March 31, 2016, 1:50 p.m.
PM QoS device latencies are properties of the hardware. Let's define some
DT bindings for them.

Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

---
 Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++
 1 file changed, 6 insertions(+)

-- 
1.9.1

Comments

Rob Herring April 1, 2016, 6:44 p.m. | #1
On Thu, Mar 31, 2016 at 03:50:25PM +0200, Ulf Hansson wrote:
> PM QoS device latencies are properties of the hardware. Let's define some

> DT bindings for them.

> 

> Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>

> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> ---

>  Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++

>  1 file changed, 6 insertions(+)

> 

> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt

> index 025b5e7..b101a20 100644

> --- a/Documentation/devicetree/bindings/power/power_domain.txt

> +++ b/Documentation/devicetree/bindings/power/power_domain.txt

> @@ -65,12 +65,18 @@ Required properties:

>   - power-domains : A phandle and PM domain specifier as defined by bindings of

>                     the power controller specified by phandle.

>  

> +Optional properties:

> + - suspend-latency: Suspend latency of the device in ns.

> + - resume-latency: Resume latency of the device in ns.


The names are a bit Linux specific, but I don't have a better 
suggestion. Could be power-up/down, but then you may have other 
latencies such as link up times.

Whatever we end up with, add a unit suffix (-ns).

Shouldn't this be split into latency of the domain (and in the domain's 
node) and latency of the device? 

> +

>  Example:

>  

>  	leaky-device@12350000 {

>  		compatible = "foo,i-leak-current";

>  		reg = <0x12350000 0x1000>;

>  		power-domains = <&power 0>;

> +		suspend-latency = <250000>;

> +		resume-latency = <250000>;

>  	};

>  

>  The node above defines a typical PM domain consumer device, which is located

> -- 

> 1.9.1

> 

> --

> To unsubscribe from this list: send the line "unsubscribe devicetree" in

> the body of a message to majordomo@vger.kernel.org

> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ulf Hansson April 4, 2016, 9:42 a.m. | #2
On 1 April 2016 at 20:44, Rob Herring <robh@kernel.org> wrote:
> On Thu, Mar 31, 2016 at 03:50:25PM +0200, Ulf Hansson wrote:

>> PM QoS device latencies are properties of the hardware. Let's define some

>> DT bindings for them.

>>

>> Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>

>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

>> ---

>>  Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++

>>  1 file changed, 6 insertions(+)

>>

>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt

>> index 025b5e7..b101a20 100644

>> --- a/Documentation/devicetree/bindings/power/power_domain.txt

>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt

>> @@ -65,12 +65,18 @@ Required properties:

>>   - power-domains : A phandle and PM domain specifier as defined by bindings of

>>                     the power controller specified by phandle.

>>

>> +Optional properties:

>> + - suspend-latency: Suspend latency of the device in ns.

>> + - resume-latency: Resume latency of the device in ns.

>

> The names are a bit Linux specific, but I don't have a better

> suggestion. Could be power-up/down, but then you may have other

> latencies such as link up times.

>

> Whatever we end up with, add a unit suffix (-ns).


Okay.

>

> Shouldn't this be split into latency of the domain (and in the domain's

> node) and latency of the device?


Yes! $Subject patch only takes device latencies into account.

Perhaps what you mean is that we should document device PM QoS
latencies in another place than
Documentation/devicetree/bindings/power/power_domain.txt as well?

Regarding bindings for the domain latencies, I will post that as a
separate patch soonish.

[...]

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ulf Hansson April 8, 2016, 11:19 a.m. | #3
[...]

>> >

>> > Shouldn't this be split into latency of the domain (and in the domain's

>> > node) and latency of the device?

>>

>> Yes! $Subject patch only takes device latencies into account.

>>

>> Perhaps what you mean is that we should document device PM QoS

>> latencies in another place than

>> Documentation/devicetree/bindings/power/power_domain.txt as well?

>

> Yes, the location is confusing that this is device latency which has

> nothing to do with power domains other than the fact we've lost all

> state (which a reset could cause too).


Okay, will a new file,
Documentation/devicetree/bindings/power/device_qos.txt make sense for
you?

>

>> Regarding bindings for the domain latencies, I will post that as a

>> separate patch soonish.

>

> It probably makes sense to look at latency bindings as a whole series.


Well, unless you insist, I would rather look at this first.

The domain latencies might be a bit more complex and those shouldn't
affect how we describe device latencies, or you think so?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring April 11, 2016, 1:29 p.m. | #4
On Fri, Apr 08, 2016 at 01:19:36PM +0200, Ulf Hansson wrote:
> [...]

> 

> >> >

> >> > Shouldn't this be split into latency of the domain (and in the domain's

> >> > node) and latency of the device?

> >>

> >> Yes! $Subject patch only takes device latencies into account.

> >>

> >> Perhaps what you mean is that we should document device PM QoS

> >> latencies in another place than

> >> Documentation/devicetree/bindings/power/power_domain.txt as well?

> >

> > Yes, the location is confusing that this is device latency which has

> > nothing to do with power domains other than the fact we've lost all

> > state (which a reset could cause too).

> 

> Okay, will a new file,

> Documentation/devicetree/bindings/power/device_qos.txt make sense for

> you?

> 

> >

> >> Regarding bindings for the domain latencies, I will post that as a

> >> separate patch soonish.

> >

> > It probably makes sense to look at latency bindings as a whole series.

> 

> Well, unless you insist, I would rather look at this first.

> 

> The domain latencies might be a bit more complex and those shouldn't

> affect how we describe device latencies, or you think so?


Probably not, but I was thinking at least property names would be 
common. Besides power domains, any external component can add latencies. 
For example, what's the latency for a display (subsystem) when you have 
display controller, phy, external bridge and panel? What I don't want to 
see in DT are people doing some simple latency that's added up all the 
components and then coming back later and saying they need to change it 
to be more fine grained and distributed to each component. 

Rob

> 

> Kind regards

> Uffe

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 025b5e7..b101a20 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -65,12 +65,18 @@  Required properties:
  - power-domains : A phandle and PM domain specifier as defined by bindings of
                    the power controller specified by phandle.
 
+Optional properties:
+ - suspend-latency: Suspend latency of the device in ns.
+ - resume-latency: Resume latency of the device in ns.
+
 Example:
 
 	leaky-device@12350000 {
 		compatible = "foo,i-leak-current";
 		reg = <0x12350000 0x1000>;
 		power-domains = <&power 0>;
+		suspend-latency = <250000>;
+		resume-latency = <250000>;
 	};
 
 The node above defines a typical PM domain consumer device, which is located