[RFC/PATCH] dt: bindings: Define bindings for device idle states

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

Commit Message

Ulf Hansson Aug. 26, 2016, 10:24 a.m.
A device may be capable of entering a low power state when it becomes
idle, which should avoid the device from wasting power.

Unfortunate entering a such low power state for a device may often also
come with a cost. This because when a new request is about to be served,
the device must first to be woken up from its low power state. As that may
take a while, the request may suffer from an initial latency.

These so called device idle states are characteristics of the hardware, so
let's define some DT bindings to enable us to describe them.

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

---

Similar DT bindings has been suggested earlier [1], although Rob raised
primarily two conserns in that approach.

*) The bindings was probably not future proof, some more flexibility was needed.

**) As the bindings also relates to idles states for PM domains, it seemed
reasonable to discuss them at the same time. As there is an ongoing discussion
for that right now [2], I took the opportunity to bring up the discussion for
device idles states again.

[1]
http://www.spinics.net/lists/devicetree/msg120515.html

[2]
http://www.spinics.net/lists/arm-kernel/msg522023.html

---
 .../bindings/power/device-idle-states.txt          | 102 +++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/device-idle-states.txt

-- 
1.9.1

Comments

Ulf Hansson Aug. 29, 2016, 11:55 a.m. | #1
On 29 August 2016 at 12:40, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2016-08-29 11:34:34, Ulf Hansson wrote:

>> On 26 August 2016 at 15:58, Pavel Machek <pavel@ucw.cz> wrote:

>> > Hi!

>> >

>> >> @@ -0,0 +1,102 @@

>> >> +Device idle states

>> >> +========================

>> >> +

>> >> +A device are often capable of entering a low power state(s) when it becomes

>> >> +idle, hence the terminology of device idle states. Entering an idle state for a

>> >> +device helps it to avoid wasting power and reduces the leakage of current.

>> >

>> > First things first: what do these states _really_ represent? We have

>> > GPIOs in device tree, we have clock domains. What are these?

>>

>> On most ARM SoCs which I am familiar of and which isn't using ACPI,

>> these kind of resources may can be considered as "power resources"

>> connected to a generic device. Although it's of course highly

>> dependent on the SoC. Other typical resources are clocks, pinctrls,

>> regulators etc.

>>

>> To enter a low power state, these devices may not explicitly have to

>> change some internal logic, but instead relies on external "power

>> resources " to be put into low power mode.

>>

>> I guess one could compare this to what can be described in the ACPI's

>> Device Power Management.

>

> If they are clocks, describe them as clocks, DT supports that. If they

> are regulators, describe them as regulators.

>

> We don't want to have "we have these magic somethings here". We want

> to know whether it is clock, regulator, or what.


This isn't something that will *replace* clocks etc. If those
resources are needed, of course those needs to be described.

What is missing in DT, and what I suggest to add, is to be able to
describe the actual idle states of a device and the HW characteristics
related to that.
In this RFC, I picked the most common properties that I could think
of, which ought to be latencies for enter and wakeup from a low power
state.

And... we also have devices that have internal logics that must be
changed to enter and wakeup from a low power state. For example WLAN
circuits, PCI devices, etc. So this isn't all about clocks/regulators
etc, but devices in general.

[...]

Kind regards
Uffe
--
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

Patch

diff --git a/Documentation/devicetree/bindings/power/device-idle-states.txt b/Documentation/devicetree/bindings/power/device-idle-states.txt
new file mode 100644
index 0000000..222fafb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/device-idle-states.txt
@@ -0,0 +1,102 @@ 
+Device idle states
+========================
+
+A device are often capable of entering a low power state(s) when it becomes
+idle, hence the terminology of device idle states. Entering an idle state for a
+device helps it to avoid wasting power and reduces the leakage of current.
+
+However, entering an idle state for a device may unfortunate often also come
+with a cost, as it could introduce a wakeup latency when a new request needs to
+be served using the device.
+
+Devices may support more than one idle state, where each state could have its
+own specific characteristic on how it impacts power saving, wakeup latency etc.
+
+These DT bindings can be used to describe these device idle states, but also to
+assign the supported idle states to devices.
+
+
+== Device idle states container node ==
+
+The device idle states are defined within a device-idle-states node, which
+provides a container where the device idle states must be listed as device tree
+nodes.
+
+
+== Device idle states nodes ==
+
+To be able to distinguish between different types of device idle states, a
+compatible string is assigned to each type. Currently one type is described,
+but this can be extended to more types if needed.
+
+Each device idle state node represents a device idle state description and must
+be defined as a child of the device idle states container node.
+
+
+== The simple device idle state type ==
+
+For most of the simple devices this type of device idle state, is sufficient to
+be able to describe the device's idle states. The supported properties can be
+extended if needed, although a more complex idle state is probably better
+described by using another type/compatible.
+
+Required properties:
+- compatible:		Must contain "simple-dev, idle-state".
+- entry-latency-ns:	An u32 value in nano-seconds representing the worst case
+			latency required for the device to enter the idle state.
+- exit-latency-ns:	An u32 value in nano-seconds representing the worst case
+			wakeup latency of the device, after entry-latency-ns has
+			passed.
+
+Optional properties:
+- idle-state-name: A string used as a descriptive name for the idle state.
+
+
+== Assigning idle states to devices ==
+
+Required properties:
+ - dev-idle-states:	A list of phandles pointing to the supported
+			device idle states nodes. The list must be ordered as
+			the shallower state - the earlier in the list.
+
+
+== Examples ==
+
+	device-idle-states {
+		RETENTION_0: dev-retention-0 {
+			compatible = "simple-dev,idle-state";
+			entry-latency-ns = <300>;
+			exit-latency-ns = <1000>;
+		};
+
+		SLEEP_0: dev-sleep-0 {
+			compatible = "simple-dev,idle-state";
+			entry-latency-us = <3000>;
+			exit-latency-us = <10000>;
+		};
+
+		SLEEP_1: dev-sleep-1 {
+			compatible = "simple-dev,idle-state";
+			entry-latency-us = <50000>;
+			exit-latency-us = <100000>;
+		};
+	};
+
+	leaky-device@12340000 {
+		compatible = "foo,i-leak-current";
+		reg = <0x12340000 0x1000>;
+		dev-idle-states = <&SLEEP_0>;
+	};
+
+	leaky-device@23450000 {
+		compatible = "foo,i-leak-current";
+		reg = <0x23450000 0x1000>;
+		dev-idle-states = <&RETENTION_0>, <&SLEEP_0>;
+	};
+
+	leaky-device@34560000 {
+		compatible = "foo,i-leak-current";
+		reg = <0x34560000 0x1000>;
+		dev-idle-states = <&SLEEP_1>;
+	};
+