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 |
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.
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. > >
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.
* 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
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.
* 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 --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.
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