| Message ID | 1459432226-22562-1-git-send-email-ulf.hansson@linaro.org |
|---|---|
| State | New |
| Headers | show |
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
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
[...] >> > >> > 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
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
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
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