[PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states

[PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states

[Lina Iyer]

Update DT bindings to describe idle states of PM domains.

This patch is based on the original patch by Marc Titinger.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/power/power_domain.txt     | 38 ++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 025b5e7..7f8f27e 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,10 @@ Optional properties:
    specified by this binding. More details about power domain specifier are
    available in the next section.
 
+- domain-idle-states : A phandle of an idle-state that shall be soaked into a
+                generic domain power state. The idle state definitions are
+                compatible with arm,idle-state specified in [1].
+
 Example:
 
 	power: power-controller@12340000 {
@@ -59,6 +63,38 @@ The nodes above define two power controllers: 'parent' and 'child'.
 Domains created by the 'child' power controller are subdomains of '0' power
 domain provided by the 'parent' power controller.
 
+Example 3:
+	parent: power-controller@12340000 {
+		compatible = "foo,power-controller";
+		reg = <0x12340000 0x1000>;
+		#power-domain-cells = <0>;
+		domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
+	};
+
+	child: power-controller@12341000 {
+		compatible = "foo,power-controller";
+		reg = <0x12341000 0x1000>;
+		power-domains = <&parent 0>;
+		#power-domain-cells = <0>;
+		domain-idle-states = <&DOMAIN_PWR_DN>;
+	};
+
+	DOMAIN_RET: state@0 {
+		compatible = "arm,idle-state";
+		reg = <0x0>;
+		entry-latency-us = <1000>;
+		exit-latency-us = <2000>;
+		min-residency-us = <10000>;
+	};
+
+	DOMAIN_PWR_DN: state@1 {
+		compatible = "arm,idle-state";
+		reg = <0x1>;
+		entry-latency-us = <5000>;
+		exit-latency-us = <8000>;
+		min-residency-us = <7000>;
+	};
+
 ==PM domain consumers==
 
 Required properties:
@@ -76,3 +112,5 @@ Example:
 The node above defines a typical PM domain consumer device, which is located
 inside a PM domain with index 0 of a power controller represented by a node
 with the label "power".
+
+[1]. Documentation/devicetree/bindings/arm/idle-states.txt
-- 
2.7.4

Re: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states

[Sudeep Holla]

On 07/10/16 23:36, Lina Iyer wrote:
> Update DT bindings to describe idle states of PM domains.
>
> This patch is based on the original patch by Marc Titinger.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>  .../devicetree/bindings/power/power_domain.txt     | 38 ++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 025b5e7..7f8f27e 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -29,6 +29,10 @@ Optional properties:
>     specified by this binding. More details about power domain specifier are
>     available in the next section.
>
> +- domain-idle-states : A phandle of an idle-state that shall be soaked into a
> +                generic domain power state. The idle state definitions are
> +                compatible with arm,idle-state specified in [1].
> +

Please do add the following details to the binding. IMO, this binding is
not complete in terms of specification as there are few open questions:

1. What not define a standard compatible instead of "arm,idle-state" ?
    I agree it can be used, but as part of this *generic* binding, IMO
    it's better to have something generic and can be used by devices.
    Otherwise, this binding becomes CPU specific, that too ARM CPU
    specific.

2. Now taking CPU as a special device, how does this co-exist with the
    cpu-idle-states ? Better to have some description may be in the ARM
    CPU idle binding document(not here of-course)

3. I still haven't seen any explanation for not considering complete
    hierarchical power domain representation which was raised in earlier
    versions. I had provided example for the proposal. I just saw them
    already in use in the upstream kernel by Renasas. e.g.:
    arch/arm/boot/dts/r8a73a4.dtsi

    How does that fit with your proposal, though you have not made one
    yet for CPUs in this binding ? In the above file, CPUs have either
    own power domain inside the L2 one which is cluster level power
    domain.

One must be able to get answers to these above questions with this
binding. Until then it's *incomplete* though it may be correct.

-- 
Regards,
Sudeep

Re: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states

[Lina Iyer]

On Mon, Oct 10 2016 at 09:45 -0600, Sudeep Holla wrote:
>
>
>On 07/10/16 23:36, Lina Iyer wrote:
>>Update DT bindings to describe idle states of PM domains.
>>
>>This patch is based on the original patch by Marc Titinger.
>>
>>Cc: <devicetree@vger.kernel.org>
>>Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>Acked-by: Rob Herring <robh@kernel.org>
>>---
>> .../devicetree/bindings/power/power_domain.txt     | 38 ++++++++++++++++++++++
>> 1 file changed, 38 insertions(+)
>>
>>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>>index 025b5e7..7f8f27e 100644
>>--- a/Documentation/devicetree/bindings/power/power_domain.txt
>>+++ b/Documentation/devicetree/bindings/power/power_domain.txt
>>@@ -29,6 +29,10 @@ Optional properties:
>>    specified by this binding. More details about power domain specifier are
>>    available in the next section.
>>
>>+- domain-idle-states : A phandle of an idle-state that shall be soaked into a
>>+                generic domain power state. The idle state definitions are
>>+                compatible with arm,idle-state specified in [1].
>>+
>
>Please do add the following details to the binding. IMO, this binding is
>not complete in terms of specification as there are few open questions:
>
>1. What not define a standard compatible instead of "arm,idle-state" ?
>   I agree it can be used, but as part of this *generic* binding, IMO
>   it's better to have something generic and can be used by devices.
>   Otherwise, this binding becomes CPU specific, that too ARM CPU
>   specific.
>
We had gone down this path of having a separate DT bindings for domains
that is not arm,idle-state. See RFC patches. But the binding did closely
match this and it so was suggested that we use arm,idle-state which is
already defined.

>2. Now taking CPU as a special device, how does this co-exist with the
>   cpu-idle-states ? Better to have some description may be in the ARM
>   CPU idle binding document(not here of-course)
>
The is a binding for a generic PM domain. This has no bearing on the CPU
or its idle states. Its just that the data is compatible with
arm,idle-state.

>3. I still haven't seen any explanation for not considering complete
>   hierarchical power domain representation which was raised in earlier
>   versions. I had provided example for the proposal. I just saw them
>   already in use in the upstream kernel by Renasas. e.g.:
>   arch/arm/boot/dts/r8a73a4.dtsi
>
Hierarchical power domains have been available for few years in DT. The
OF features of domains have always supported it. Platforms are free to
define domains in hierarchy they seem fit for their SoCs. This is a
feature that is available today and is not being modified in these
patches. It will be creating confusion if I talk about hierarchical
domains which are obvious and irrelevant to this series.

>   How does that fit with your proposal, though you have not made one
>   yet for CPUs in this binding ? In the above file, CPUs have either
>   own power domain inside the L2 one which is cluster level power
>   domain.
>
Again, this series is not about the CPUs. This is about adding features
to genpd that may be used in other contexts including cpuidle in the
future.

>One must be able to get answers to these above questions with this
>binding. Until then it's *incomplete* though it may be correct.
>
I have always tried to answer all your questions. If anything remains
unclarified pls. bring it up.

Thanks,
Lina

Re: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states

[Sudeep Holla]

On 10/10/16 17:43, Lina Iyer wrote:
> On Mon, Oct 10 2016 at 09:45 -0600, Sudeep Holla wrote:
>>
>>
>> On 07/10/16 23:36, Lina Iyer wrote:
>>> Update DT bindings to describe idle states of PM domains.
>>>
>>> This patch is based on the original patch by Marc Titinger.
>>>
>>> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>> Signed-off-by: Marc Titinger <mtitinger+renesas-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Signed-off-by: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/power/power_domain.txt     | 38
>>> ++++++++++++++++++++++
>>> 1 file changed, 38 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
>>> b/Documentation/devicetree/bindings/power/power_domain.txt
>>> index 025b5e7..7f8f27e 100644
>>> --- a/Documentation/devicetree/bindings/power/power_domain.txt
>>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
>>> @@ -29,6 +29,10 @@ Optional properties:
>>>    specified by this binding. More details about power domain
>>> specifier are
>>>    available in the next section.
>>>
>>> +- domain-idle-states : A phandle of an idle-state that shall be
>>> soaked into a
>>> +                generic domain power state. The idle state
>>> definitions are
>>> +                compatible with arm,idle-state specified in [1].
>>> +
>>
>> Please do add the following details to the binding. IMO, this binding is
>> not complete in terms of specification as there are few open questions:
>>
>> 1. What not define a standard compatible instead of "arm,idle-state" ?
>>   I agree it can be used, but as part of this *generic* binding, IMO
>>   it's better to have something generic and can be used by devices.
>>   Otherwise, this binding becomes CPU specific, that too ARM CPU
>>   specific.
>>
> We had gone down this path of having a separate DT bindings for domains
> that is not arm,idle-state. See RFC patches. But the binding did closely
> match this and it so was suggested that we use arm,idle-state which is
> already defined.
>

Either we say this binding is ARM CPU specific or generic, I can't
understand this mix 'n' match really. You have removed all the CPUIdle
stuff from this series which is good and makes it simpler, but linking
it to only "arm,idle-state" make be feel it's not generic. OK I will
have a look at the RFC as why generic compatible was rejected.

>> 2. Now taking CPU as a special device, how does this co-exist with the
>>   cpu-idle-states ? Better to have some description may be in the ARM
>>   CPU idle binding document(not here of-course)
>>
> The is a binding for a generic PM domain. This has no bearing on the CPU
> or its idle states. Its just that the data is compatible with
> arm,idle-state.
>

I understand that but it's not that simple which I assume you *do*
agree. Hence may need bit of an explanation in the binding(not here
of-course as I mentioned earlier, but in the CPU Idle bindings).
Please consider DT bindings as any other specification. All I am
asking is more description in the binding.

>> 3. I still haven't seen any explanation for not considering complete
>>   hierarchical power domain representation which was raised in earlier
>>   versions. I had provided example for the proposal. I just saw them
>>   already in use in the upstream kernel by Renasas. e.g.:
>>   arch/arm/boot/dts/r8a73a4.dtsi
>>
> Hierarchical power domains have been available for few years in DT. The
> OF features of domains have always supported it. Platforms are free to
> define domains in hierarchy they seem fit for their SoCs. This is a
> feature that is available today and is not being modified in these
> patches. It will be creating confusion if I talk about hierarchical
> domains which are obvious and irrelevant to this series.
>

Agreed and sorry if I created any confusion. But this binding doesn't
clearly state how to build up the hierarchy if the leaf node is not a
power-domain node and I am just trying have those clarifications in the
binding. It would be good if those details are *explicitly* mentioned in
the binding, not this particularly, but in CPU Idle one when you
introduce the user of that.

>>   How does that fit with your proposal, though you have not made one
>>   yet for CPUs in this binding ? In the above file, CPUs have either
>>   own power domain inside the L2 one which is cluster level power
>>   domain.
>>
> Again, this series is not about the CPUs. This is about adding features
> to genpd that may be used in other contexts including cpuidle in the
> future.
>

Yes I understand and hence I was confused as why I don't see an
*generic* compatible but just *arm,idle-states* in the example.

>> One must be able to get answers to these above questions with this
>> binding. Until then it's *incomplete* though it may be correct.
>>
> I have always tried to answer all your questions. If anything remains
> unclarified pls. bring it up.
>

It's not about questions, and definitely you have answered all my
questions, no argument there at all. Now we need to make those useful
discussions part of this binding so that it's *self explanatory* and
one need not refer back these discussions when writing DT for some
different SoC which differs from this. Again that could be part of
your CPUIdle series, I just raised it here as it got mixed sense from
this series. It was hard to be not to associate CPUIdle for reasons
mentioned above.

-- 
Regards,
Sudeep
--
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

Re: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states

[Sudeep Holla]

On 10/10/16 17:43, Lina Iyer wrote:
> On Mon, Oct 10 2016 at 09:45 -0600, Sudeep Holla wrote:
>>
>>
>> On 07/10/16 23:36, Lina Iyer wrote:
>>> Update DT bindings to describe idle states of PM domains.
>>>
>>> This patch is based on the original patch by Marc Titinger.
>>>
>>> Cc: <devicetree@vger.kernel.org>
>>> Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> ---
>>> .../devicetree/bindings/power/power_domain.txt     | 38
>>> ++++++++++++++++++++++
>>> 1 file changed, 38 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
>>> b/Documentation/devicetree/bindings/power/power_domain.txt
>>> index 025b5e7..7f8f27e 100644
>>> --- a/Documentation/devicetree/bindings/power/power_domain.txt
>>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
>>> @@ -29,6 +29,10 @@ Optional properties:
>>>    specified by this binding. More details about power domain
>>> specifier are
>>>    available in the next section.
>>>
>>> +- domain-idle-states : A phandle of an idle-state that shall be
>>> soaked into a
>>> +                generic domain power state. The idle state
>>> definitions are
>>> +                compatible with arm,idle-state specified in [1].
>>> +
>>
>> Please do add the following details to the binding. IMO, this binding is
>> not complete in terms of specification as there are few open questions:
>>
>> 1. What not define a standard compatible instead of "arm,idle-state" ?
>>   I agree it can be used, but as part of this *generic* binding, IMO
>>   it's better to have something generic and can be used by devices.
>>   Otherwise, this binding becomes CPU specific, that too ARM CPU
>>   specific.
>>
> We had gone down this path of having a separate DT bindings for domains
> that is not arm,idle-state. See RFC patches. But the binding did closely
> match this and it so was suggested that we use arm,idle-state which is
> already defined.
>

Are you referring to [1] here ? Sorry, I did some search quickly and
could find this, wanted to check if I am looking at the right one ?

-- 
Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/353261.html

Re: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states

[Lina Iyer]

On Mon, Oct 10 2016 at 11:13 -0600, Sudeep Holla wrote:
>
>
>On 10/10/16 17:43, Lina Iyer wrote:
>>On Mon, Oct 10 2016 at 09:45 -0600, Sudeep Holla wrote:
>>>
>>>
>>>On 07/10/16 23:36, Lina Iyer wrote:
>>>>Update DT bindings to describe idle states of PM domains.
>>>>
>>>>This patch is based on the original patch by Marc Titinger.
>>>>
>>>>Cc: <devicetree@vger.kernel.org>
>>>>Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>>>>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>>Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>>>Acked-by: Rob Herring <robh@kernel.org>
>>>>---
>>>>.../devicetree/bindings/power/power_domain.txt     | 38
>>>>++++++++++++++++++++++
>>>>1 file changed, 38 insertions(+)
>>>>
>>>>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
>>>>b/Documentation/devicetree/bindings/power/power_domain.txt
>>>>index 025b5e7..7f8f27e 100644
>>>>--- a/Documentation/devicetree/bindings/power/power_domain.txt
>>>>+++ b/Documentation/devicetree/bindings/power/power_domain.txt
>>>>@@ -29,6 +29,10 @@ Optional properties:
>>>>   specified by this binding. More details about power domain
>>>>specifier are
>>>>   available in the next section.
>>>>
>>>>+- domain-idle-states : A phandle of an idle-state that shall be
>>>>soaked into a
>>>>+                generic domain power state. The idle state
>>>>definitions are
>>>>+                compatible with arm,idle-state specified in [1].
>>>>+
>>>
>>>Please do add the following details to the binding. IMO, this binding is
>>>not complete in terms of specification as there are few open questions:
>>>
>>>1. What not define a standard compatible instead of "arm,idle-state" ?
>>>  I agree it can be used, but as part of this *generic* binding, IMO
>>>  it's better to have something generic and can be used by devices.
>>>  Otherwise, this binding becomes CPU specific, that too ARM CPU
>>>  specific.
>>>
>>We had gone down this path of having a separate DT bindings for domains
>>that is not arm,idle-state. See RFC patches. But the binding did closely
>>match this and it so was suggested that we use arm,idle-state which is
>>already defined.
>>
>
>Either we say this binding is ARM CPU specific or generic, I can't
>understand this mix 'n' match really. You have removed all the CPUIdle
>stuff from this series which is good and makes it simpler, but linking
>it to only "arm,idle-state" make be feel it's not generic. OK I will
>have a look at the RFC as why generic compatible was rejected.
>
I will look for the discussion around it as well. A initial look through
didn't get me the thread I was looking for.

>>>2. Now taking CPU as a special device, how does this co-exist with the
>>>  cpu-idle-states ? Better to have some description may be in the ARM
>>>  CPU idle binding document(not here of-course)
>>>
>>The is a binding for a generic PM domain. This has no bearing on the CPU
>>or its idle states. Its just that the data is compatible with
>>arm,idle-state.
>>
>
>I understand that but it's not that simple which I assume you *do*
>agree. Hence may need bit of an explanation in the binding(not here
>of-course as I mentioned earlier, but in the CPU Idle bindings).
>Please consider DT bindings as any other specification. All I am
>asking is more description in the binding.
>
Any ideas of what description you would like to see? It seemed fairly
explanatory in the idle-states.txt, so I didn't go into depth here.

>>>3. I still haven't seen any explanation for not considering complete
>>>  hierarchical power domain representation which was raised in earlier
>>>  versions. I had provided example for the proposal. I just saw them
>>>  already in use in the upstream kernel by Renasas. e.g.:
>>>  arch/arm/boot/dts/r8a73a4.dtsi
>>>
>>Hierarchical power domains have been available for few years in DT. The
>>OF features of domains have always supported it. Platforms are free to
>>define domains in hierarchy they seem fit for their SoCs. This is a
>>feature that is available today and is not being modified in these
>>patches. It will be creating confusion if I talk about hierarchical
>>domains which are obvious and irrelevant to this series.
>>
>
>Agreed and sorry if I created any confusion. But this binding doesn't
>clearly state how to build up the hierarchy if the leaf node is not a
>power-domain node and I am just trying have those clarifications in the
>binding. It would be good if those details are *explicitly* mentioned in
>the binding, not this particularly, but in CPU Idle one when you
>introduce the user of that.
>
As we have today, devices have their own way of figuring out their idle
states, they are not represented in DT (CPU being an exception). 

>>>  How does that fit with your proposal, though you have not made one
>>>  yet for CPUs in this binding ? In the above file, CPUs have either
>>>  own power domain inside the L2 one which is cluster level power
>>>  domain.
>>>
>>Again, this series is not about the CPUs. This is about adding features
>>to genpd that may be used in other contexts including cpuidle in the
>>future.
>>
>
>Yes I understand and hence I was confused as why I don't see an
>*generic* compatible but just *arm,idle-states* in the example.
>
>>>One must be able to get answers to these above questions with this
>>>binding. Until then it's *incomplete* though it may be correct.
>>>
>>I have always tried to answer all your questions. If anything remains
>>unclarified pls. bring it up.
>>
>
>It's not about questions, and definitely you have answered all my
>questions, no argument there at all. Now we need to make those useful
>discussions part of this binding so that it's *self explanatory* and
>one need not refer back these discussions when writing DT for some
>different SoC which differs from this. Again that could be part of
>your CPUIdle series, I just raised it here as it got mixed sense from
>this series. It was hard to be not to associate CPUIdle for reasons
>mentioned above.
>

Thanks,
Lina

Re: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states

[Sudeep Holla]

On 10/10/16 23:13, Lina Iyer wrote:
> On Mon, Oct 10 2016 at 11:13 -0600, Sudeep Holla wrote:

[...]

>> Either we say this binding is ARM CPU specific or generic, I can't
>> understand this mix 'n' match really. You have removed all the
>> CPUIdle stuff from this series which is good and makes it simpler,
>> but linking it to only "arm,idle-state" make be feel it's not
>> generic. OK I will have a look at the RFC as why generic compatible
>> was rejected.
>>
> I will look for the discussion around it as well. A initial look
> through didn't get me the thread I was looking for.
>

Sure

[...]

>>
>> I understand that but it's not that simple which I assume you *do*
>> agree. Hence may need bit of an explanation in the binding(not here
>> of-course as I mentioned earlier, but in the CPU Idle bindings).
>> Please consider DT bindings as any other specification. All I am
>> asking is more description in the binding.
>>
> Any ideas of what description you would like to see? It seemed fairly
> explanatory in the idle-states.txt, so I didn't go into depth here.
>

Various use cases we discussed and what takes precedence,... etc
E.g.: if the Renasas example I pointed out had cpu-idle-states and
power-domain but no domain-idle-states which is perfectly valid without
this bindings.

Basically all the important this we have discussed so far. Even the
OSC/PCC is worth mentioning so that we are explicitly clear that this
binding has no affiliation to those PSCI methods. In short it should be
able to answer any question one might get if is completely new to this
binding but is aware of old one.

[...]

>>
>> Agreed and sorry if I created any confusion. But this binding doesn't
>> clearly state how to build up the hierarchy if the leaf node is not a
>> power-domain node and I am just trying have those clarifications in the
>> binding. It would be good if those details are *explicitly* mentioned in
>> the binding, not this particularly, but in CPU Idle one when you
>> introduce the user of that.
>>
> As we have today, devices have their own way of figuring out their idle
> states, they are not represented in DT (CPU being an exception).

I understand that, and I assume this binding will provide a way to
represent that for devices too if required. No ? Otherwise I see no
point in just saying it's generic.

-- 
Regards,
Sudeep