On 10 November 2016 at 20:58, Rob Herring [off-list ref] wrote:

On Mon, Nov 07, 2016 at 12:14:28PM +0100, Ulf Hansson wrote:

quoted

On 3 November 2016 at 22:54, Lina Iyer [off-list ref] wrote:

quoted

Re-using idle state definition provided by arm,idle-state for domain
idle states creates a lot of confusion and limits further evolution of
the domain idle definition. To keep things clear and simple, define a
idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc: <redacted>
Cc: Rob Herring <redacted>
Signed-off-by: Lina Iyer <redacted>
---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
new file mode 100644
index 0000000..eefc7ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt

@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required
+       Value type: <string>
+       Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+       Usage: Required
+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency in
+                   microseconds required to enter the idle state.
+                   The exit-latency-us duration may be guaranteed
+                   only after entry-latency-us has passed.

As we anyway are going to change this, why not use an u64 and have the
value in ns instead of us?

I can't imagine that you would need more resolution or range. For times
less than 1us, s/w and register access times are going to dominate the
time.

Yep.

Unless there is a real need, I'd keep alignment with the existing
binding.

Agree!

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html