diff mbox series

dt-bindings: power: Introduce suspend states supported properties

Message ID 1536725372-29174-1-git-send-email-j-keerthy@ti.com (mailing list archive)
State New, archived
Headers show
Series dt-bindings: power: Introduce suspend states supported properties | expand

Commit Message

J, KEERTHY Sept. 12, 2018, 4:09 a.m. UTC
Introuduce linux generic suspend states supported properties.
It is convenient for the generic suspend path to have
the knowledge of the suspend states supported based on the
device tree properties based on which it can either be suspended
or safely bailed out of suspend if none of the suspend states
are supported.

Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 .../devicetree/bindings/power/power-states.txt     | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/power-states.txt

Comments

Sudeep Holla Sept. 12, 2018, 11:02 a.m. UTC | #1
On 12/09/18 05:09, Keerthy wrote:
> Introuduce linux generic suspend states supported properties.
> It is convenient for the generic suspend path to have
> the knowledge of the suspend states supported based on the
> device tree properties based on which it can either be suspended
> or safely bailed out of suspend if none of the suspend states
> are supported.
> 

NACK for any bindings that are linux specific. The suspend feature is so
platform dependent that I see no need for generic Linux bindings for the
same.

We have power domains and idle states. If you have platforms that
doesn't support some of the states, just disable them in the DT.

> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
>  .../devicetree/bindings/power/power-states.txt     | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/power-states.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/power-states.txt b/Documentation/devicetree/bindings/power/power-states.txt
> new file mode 100644
> index 0000000..bb80b36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power-states.txt
> @@ -0,0 +1,22 @@
> +* Generic system suspend states support
> +
> +Most platforms support multiple suspend states. Define system
> +suspend states so that one can target appropriate low power
> +states based on the SoC capabilities.
> +
> +linux,suspend-to-memory-supported
> +
> +Upon suspend to memory the system context is saved to primary memory.
> +All the clocks for all the peripherals including CPU are gated.
> +
> +linux,suspend-power-off-supported
> +
> +In this case in additon to the clocks all the voltage resources are
> +turned off except the ones needed to keep the primary memory
> +and a wake up source that can trigger a wakeup event.
> +
> +linux,suspend-to-disk-supported
> +
> +Upon suspend to disk that system context is saved to secondary memory.
> +All the clocks for all the peripherals including CPU are gated. Even
> +the primary memory is turned off.
> 

What makes any of the above linux specific. So once again NACK.
J, KEERTHY Sept. 12, 2018, 11:19 a.m. UTC | #2
On Wednesday 12 September 2018 04:32 PM, Sudeep Holla wrote:
> 
> 
> On 12/09/18 05:09, Keerthy wrote:
>> Introuduce linux generic suspend states supported properties.
>> It is convenient for the generic suspend path to have
>> the knowledge of the suspend states supported based on the
>> device tree properties based on which it can either be suspended
>> or safely bailed out of suspend if none of the suspend states
>> are supported.
>>
> 
> NACK for any bindings that are linux specific. The suspend feature is so
> platform dependent that I see no need for generic Linux bindings for the
> same.

suspend to mem and suspend to disk are pretty generic states and i agree
implementation is platform dependent so why not have properties that
convey if they are supported?

Is the disagreement over making the properties being linux specific?

> 
> We have power domains and idle states. If you have platforms that
> doesn't support some of the states, just disable them in the DT.
> 
>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>> ---
>>  .../devicetree/bindings/power/power-states.txt     | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/power/power-states.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/power-states.txt b/Documentation/devicetree/bindings/power/power-states.txt
>> new file mode 100644
>> index 0000000..bb80b36
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/power-states.txt
>> @@ -0,0 +1,22 @@
>> +* Generic system suspend states support
>> +
>> +Most platforms support multiple suspend states. Define system
>> +suspend states so that one can target appropriate low power
>> +states based on the SoC capabilities.
>> +
>> +linux,suspend-to-memory-supported
>> +
>> +Upon suspend to memory the system context is saved to primary memory.
>> +All the clocks for all the peripherals including CPU are gated.
>> +
>> +linux,suspend-power-off-supported
>> +
>> +In this case in additon to the clocks all the voltage resources are
>> +turned off except the ones needed to keep the primary memory
>> +and a wake up source that can trigger a wakeup event.
>> +
>> +linux,suspend-to-disk-supported
>> +
>> +Upon suspend to disk that system context is saved to secondary memory.
>> +All the clocks for all the peripherals including CPU are gated. Even
>> +the primary memory is turned off.
>>
> 
> What makes any of the above linux specific. So once again NACK.
> 
>
Sudeep Holla Sept. 12, 2018, 11:37 a.m. UTC | #3
On 12/09/18 12:19, Keerthy wrote:
> 
> 
> On Wednesday 12 September 2018 04:32 PM, Sudeep Holla wrote:
>>
>>
>> On 12/09/18 05:09, Keerthy wrote:
>>> Introuduce linux generic suspend states supported properties.
>>> It is convenient for the generic suspend path to have
>>> the knowledge of the suspend states supported based on the
>>> device tree properties based on which it can either be suspended
>>> or safely bailed out of suspend if none of the suspend states
>>> are supported.
>>>
>>
>> NACK for any bindings that are linux specific. The suspend feature is so
>> platform dependent that I see no need for generic Linux bindings for the
>> same.
> 
> suspend to mem and suspend to disk are pretty generic states and i agree
> implementation is platform dependent so why not have properties that
> convey if they are supported?
> 

We already have power domains and idle states for that. If you need to
restrict few states on some platform for whatever reasons, just disable
those states. I don't see the need to add any more bindings for the same.

> Is the disagreement over making the properties being linux specific?
> 

Yes.
Tony Lindgren Sept. 12, 2018, 1:32 p.m. UTC | #4
* Sudeep Holla <sudeep.holla@arm.com> [180912 11:41]:
> On 12/09/18 12:19, Keerthy wrote:
> > suspend to mem and suspend to disk are pretty generic states and i agree
> > implementation is platform dependent so why not have properties that
> > convey if they are supported?
> > 
> 
> We already have power domains and idle states for that. If you need to
> restrict few states on some platform for whatever reasons, just disable
> those states. I don't see the need to add any more bindings for the same.

Oh do you mean the "domain-idle-states" property as mentioned in the
Documentation/devicetree/bindings/power/power_domain.txt?

Yeah that should do and the DOMAIN_PWR_DN and DOMAIN_RET can be SoC
specific and then the board can select which ones to use depending on
how things are wired for GPIOs, memory, PMIC and so on.

Hmm I don't see any users for this binding though?

Regards,

Tony
Sudeep Holla Sept. 12, 2018, 1:42 p.m. UTC | #5
On 12/09/18 14:32, Tony Lindgren wrote:
> * Sudeep Holla <sudeep.holla@arm.com> [180912 11:41]:
>> On 12/09/18 12:19, Keerthy wrote:
>>> suspend to mem and suspend to disk are pretty generic states and i agree
>>> implementation is platform dependent so why not have properties that
>>> convey if they are supported?
>>>
>>
>> We already have power domains and idle states for that. If you need to
>> restrict few states on some platform for whatever reasons, just disable
>> those states. I don't see the need to add any more bindings for the same.
> 
> Oh do you mean the "domain-idle-states" property as mentioned in the
> Documentation/devicetree/bindings/power/power_domain.txt?
> 

Yes, exactly that.

> Yeah that should do and the DOMAIN_PWR_DN and DOMAIN_RET can be SoC
> specific and then the board can select which ones to use depending on
> how things are wired for GPIOs, memory, PMIC and so on.
>

All the idle-states are platform specific. DOMAIN_RET and DOMAIN_PWR_DN
are just examples used in the bindings.

> Hmm I don't see any users for this binding though?
> 

It was added specifically to deal with such SoC idles states or
hierarchical CPU power domains states, no users in upstream yet. But IMO
it fits what $subject is trying to address.
Tony Lindgren Sept. 12, 2018, 2:01 p.m. UTC | #6
* Sudeep Holla <sudeep.holla@arm.com> [180912 13:47]:
> 
> 
> On 12/09/18 14:32, Tony Lindgren wrote:
> > * Sudeep Holla <sudeep.holla@arm.com> [180912 11:41]:
> >> On 12/09/18 12:19, Keerthy wrote:
> >>> suspend to mem and suspend to disk are pretty generic states and i agree
> >>> implementation is platform dependent so why not have properties that
> >>> convey if they are supported?
> >>>
> >>
> >> We already have power domains and idle states for that. If you need to
> >> restrict few states on some platform for whatever reasons, just disable
> >> those states. I don't see the need to add any more bindings for the same.
> > 
> > Oh do you mean the "domain-idle-states" property as mentioned in the
> > Documentation/devicetree/bindings/power/power_domain.txt?
> > 
> 
> Yes, exactly that.

OK

> > Yeah that should do and the DOMAIN_PWR_DN and DOMAIN_RET can be SoC
> > specific and then the board can select which ones to use depending on
> > how things are wired for GPIOs, memory, PMIC and so on.
> >
> 
> All the idle-states are platform specific. DOMAIN_RET and DOMAIN_PWR_DN
> are just examples used in the bindings.
> 
> > Hmm I don't see any users for this binding though?
> > 
> 
> It was added specifically to deal with such SoC idles states or
> hierarchical CPU power domains states, no users in upstream yet. But IMO
> it fits what $subject is trying to address.

OK great thanks for confirming that.

Regards,

Tony
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/power/power-states.txt b/Documentation/devicetree/bindings/power/power-states.txt
new file mode 100644
index 0000000..bb80b36
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power-states.txt
@@ -0,0 +1,22 @@ 
+* Generic system suspend states support
+
+Most platforms support multiple suspend states. Define system
+suspend states so that one can target appropriate low power
+states based on the SoC capabilities.
+
+linux,suspend-to-memory-supported
+
+Upon suspend to memory the system context is saved to primary memory.
+All the clocks for all the peripherals including CPU are gated.
+
+linux,suspend-power-off-supported
+
+In this case in additon to the clocks all the voltage resources are
+turned off except the ones needed to keep the primary memory
+and a wake up source that can trigger a wakeup event.
+
+linux,suspend-to-disk-supported
+
+Upon suspend to disk that system context is saved to secondary memory.
+All the clocks for all the peripherals including CPU are gated. Even
+the primary memory is turned off.