On Mon, Apr 04, 2016 at 11:42:04AM +0200, Ulf Hansson wrote: > On 1 April 2016 at 20:44, Rob Herring <robh@xxxxxxxxxx> 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@xxxxxxxxx> > >> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> > >> --- > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
