| Message ID | 1410893339-6361-3-git-send-email-geert+renesas@glider.be |
|---|---|
| State | Superseded, archived |
| Headers | show |
Geert Uytterhoeven <geert+renesas@glider.be> writes: > PM QoS device start/stop and save/restore state latencies are more or > less properties of the hardware. > In legacy code, they're specified from platform code. > On DT platforms, their values should come from DT. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > Should these properties be called "linux,*-latency"? Hmm, the start/stop latencies are clearly properties of the hardware, but the save/restore latencies seem to be a function of the driver. e.g., some drivers may keep a shadow copy of their registers in memory so the save time is minimized. I don't have too strong of an opinion on this, but probably the drivers should just add their own values to the start/stop latencies to add the linux specific overhead. Kevin -- 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
Hi Kevin, On Thu, Sep 25, 2014 at 11:31 PM, Kevin Hilman <khilman@kernel.org> wrote: > Geert Uytterhoeven <geert+renesas@glider.be> writes: >> PM QoS device start/stop and save/restore state latencies are more or >> less properties of the hardware. >> In legacy code, they're specified from platform code. >> On DT platforms, their values should come from DT. >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> --- >> Should these properties be called "linux,*-latency"? > > Hmm, the start/stop latencies are clearly properties of the hardware, > but the save/restore latencies seem to be a function of the driver. > e.g., some drivers may keep a shadow copy of their registers in memory > so the save time is minimized. > > I don't have too strong of an opinion on this, but probably the drivers > should just add their own values to the start/stop latencies to add the > linux specific overhead. Thanks. I agree with you on this, so I'll remove the save/restore latencies. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt index 7bc421d84367d636..024815bc257723b1 100644 --- a/Documentation/devicetree/bindings/power/power_domain.txt +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -42,12 +42,22 @@ Required properties: - power-domains : A phandle and PM domain specifier as defined by bindings of the power controller specified by phandle. +Optional properties: + - stop-latency: Stop latency of the device, in ns, + - start-latency: Start latency of the device, in ns, + - save-state-latency: Save-state latency of the device, in ns, + - restore-state-latency: Restore-state latency of the device, in ns. + Example: leaky-device@12350000 { compatible = "foo,i-leak-current"; reg = <0x12350000 0x1000>; power-domains = <&power 0>; + stop-latency = <250000>; + start-latency = <250000>; + save-state-latency = <250000>; + restore-state-latency = <250000>; }; The node above defines a typical PM domain consumer device, which is located
PM QoS device start/stop and save/restore state latencies are more or less properties of the hardware. In legacy code, they're specified from platform code. On DT platforms, their values should come from DT. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- Should these properties be called "linux,*-latency"? v2: - New --- Documentation/devicetree/bindings/power/power_domain.txt | 10 ++++++++++ 1 file changed, 10 insertions(+)