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

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

[Ulf Hansson]

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.
+
 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

[PATCH 2/2] PM / Domains: Retrieve PM QoS device latencies from DT

[Ulf Hansson]

For the DT based device attach process, let's parse the device node for
PM QoS latency properties and provide the result as the timing data when
adding a device to its PM domain.

In DT based platforms, this change allows a device to have initial correct
latency values. In the ideal scenario it should mean that the calibration
of these values shouldn't be needed by the genpd governor, but let's leave
that as a future change to consider.

Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/base/power/domain.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 56705b5..f3302a9 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1790,6 +1790,7 @@ int genpd_dev_pm_attach(struct device *dev)
 {
 	struct of_phandle_args pd_args;
 	struct generic_pm_domain *pd;
+	struct gpd_timing_data td;
 	unsigned int i;
 	int ret;
 
@@ -1824,10 +1825,16 @@ int genpd_dev_pm_attach(struct device *dev)
 		return -EPROBE_DEFER;
 	}
 
+	memset(&td, 0, sizeof(td));
+	of_property_read_u64(dev->of_node, "suspend-latency",
+			&td.suspend_latency_ns);
+	of_property_read_u64(dev->of_node, "resume-latency",
+			&td.resume_latency_ns);
+
 	dev_dbg(dev, "adding to PM domain %s\n", pd->name);
 
 	for (i = 1; i < GENPD_RETRY_MAX_MS; i <<= 1) {
-		ret = pm_genpd_add_device(pd, dev);
+		ret = __pm_genpd_add_device(pd, dev, &td);
 		if (ret != -EAGAIN)
 			break;
 
-- 
1.9.1

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

[Rob Herring]

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

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

[Ulf Hansson]

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

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

[Rob Herring]

On Mon, Apr 04, 2016 at 11:42:04AM +0200, Ulf Hansson wrote:
> 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?

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).

> 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.

Rob

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

[Ulf Hansson]

[...]

>> >
>> > 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

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

[Rob Herring]

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