Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1584889 > unrolled thread

[PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

Back to article view | Back to linux.kernel

Contents

  [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert+renesas@glider.be> - 2017-02-20 21:40 +0100
    [PATCH/RFC 2/6] PM / Wakeup: Add wakeup_source_available() Geert Uytterhoeven <geert+renesas@glider.be> - 2017-02-20 21:40 +0100
    [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode Geert Uytterhoeven <geert+renesas@glider.be> - 2017-02-20 21:40 +0100
      Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 11:50 +0100
        Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-21 17:30 +0100
          Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 18:00 +0100
      Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Pavel Machek <pavel@ucw.cz> - 2017-02-21 12:10 +0100
        Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 12:20 +0100
          Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-21 17:40 +0100
            Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 18:30 +0100
              Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-22 14:50 +0100
                Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Sudeep Holla <sudeep.holla@arm.com> - 2017-02-22 15:40 +0100
            Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Mark Rutland <mark.rutland@arm.com> - 2017-02-21 18:30 +0100
              Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-21 19:10 +0100
                Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Mark Rutland <mark.rutland@arm.com> - 2017-02-21 19:20 +0100
                  Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow  suspend mode Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-21 19:30 +0100
    [PATCH/RFC 1/6] alarmtimer: Postpone wake-up source registration until really available Geert Uytterhoeven <geert+renesas@glider.be> - 2017-02-20 21:40 +0100
    [PATCH/RFC 6/6] arm64: dts: r8a7796: Fix non-PMIC wake-up sources Geert Uytterhoeven <geert+renesas@glider.be> - 2017-02-20 21:40 +0100
    [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert+renesas@glider.be> - 2017-02-20 21:40 +0100
      Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 12:00 +0100
        Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-21 17:40 +0100
          Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 17:50 +0100
      Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power Pavel Machek <pavel@ucw.cz> - 2017-02-21 12:10 +0100
        Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-21 17:40 +0100
        Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power Mark Rutland <mark.rutland@arm.com> - 2017-02-21 19:00 +0100
      Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power Mark Rutland <mark.rutland@arm.com> - 2017-02-21 18:50 +0100
        Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-22 15:10 +0100
          Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if  SYSTEM_SUSPEND cuts power "Rafael J. Wysocki" <rafael@kernel.org> - 2017-02-22 16:00 +0100
    Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 11:40 +0100
      Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-21 17:30 +0100
        Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 17:50 +0100
          Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-21 18:40 +0100
            Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 19:00 +0100
              Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 19:40 +0100
                Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-21 19:50 +0100
                  Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-02-22 02:30 +0100
                    Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-22 12:10 +0100
                      Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-22 14:40 +0100
                        Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-22 15:40 +0100
                          Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power "Rafael J. Wysocki" <rafael@kernel.org> - 2017-02-22 16:00 +0100
                            Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-22 17:00 +0100
                          Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-23 16:30 +0100
                            Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-23 16:40 +0100
                              Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-23 17:00 +0100
                            Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts  power Sudeep Holla <sudeep.holla@arm.com> - 2017-02-23 17:00 +0100
                    Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-22 14:20 +0100
                      Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power "Rafael J. Wysocki" <rafael@kernel.org> - 2017-02-22 15:40 +0100

Page 1 of 3  [1] 2 3  Next page →

#1584889 — [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

	Hi all,

This patch series adds support for using non-PMIC wake-up sources on the
Renesas R-Car Gen3 (H3 or M3-W) Salvator-X development boards.

Nothing in the PSCI specification requires the SoC to remain powered and
to support wake-up sources when suspended using SYSTEM_SUSPEND.
If the firmware implements the PSCI SYSTEM_SUSPEND operation by cutting
power to the SoC, the only possibly wake-up sources are thus the ones
connected to the PMIC.

To allow other wake-up sources, this patch series documents and adds
support for an "arm,psci-system-suspend-is-power-down" DT property, so
Linux uses a different suspend method when other wake-up sources (e.g.
wake on LAN, UART or GPIO) are enabled.  Hence the user no longer has to
manually restrict "mem" suspend to "s2idle" or "shallow" states using:

    $ echo s2idle > /sys/power/mem_sleep # or "shallow"

Contents:
  - Patch 1 prevents the alarmtimer from showing up as a wake-up source
    when no wake-up capable RTC device is present in the system,
  - Patch 2 provides an API to check if any wake-up sources have been
    registered,
  - Patch 3 implements "shallow" suspend mode on systems using PSCI,
    in addition to the existing "s2idle" and "deep" suspend modes,
  - Patch 4 makes the system use "shallow" instead of "deep" suspend
    mode on systems where this is needed to support non-PMIC wake-up
    sources,
  - Patches 5 and 6 enable the above on Renesas R-Car H3 and M3-W
    systems.

Dependencies:
  - The three first patches are independent,
  - The fourth patch depends on the first three patches,
  - The DTS patches depend on acceptance of the DT bindings in patch 4.

This has been tested on both the Renesas R-Car H3 (quad A57*)
and M3-W (dual A57*) Salvator-X development boards
(*A53 cores are unused).

Power consumption:

		H3	M3-W
		--	----
  - idle:	9.2 W	7.6 W
  - s2idle:	8.6 W	6.3 W
  - shallow:	8.4 W	6.2 W	(secondary CPU cores off)
  - deep:	1.4 W	1.2 W	(PSCI_SYSTEM_SUSPEND)
  - shutdown:	7.7 W	5.6 W	(PSCI SYSTEM_OFF: needs improvement)
  - poweroff:	1.3 W	1.1 W	(fan running)

Thanks for your comments!

Geert Uytterhoeven (6):
  alarmtimer: Postpone wake-up source registration until really
    available
  PM / Wakeup: Add wakeup_source_available()
  drivers: firmware: psci: Implement shallow suspend mode
  drivers: firmware: psci: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts
    power
  arm64: dts: r8a7795: Fix non-PMIC wake-up sources
  arm64: dts: r8a7796: Fix non-PMIC wake-up sources

 Documentation/devicetree/bindings/arm/psci.txt | 11 ++++++++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi       |  1 +
 arch/arm64/boot/dts/renesas/r8a7796.dtsi       |  1 +
 drivers/base/power/wakeup.c                    |  8 ++++++
 drivers/firmware/psci.c                        | 39 ++++++++++++++++++++++++--
 include/linux/pm_wakeup.h                      |  3 ++
 kernel/time/alarmtimer.c                       |  9 +++++-
 7 files changed, 68 insertions(+), 4 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[toc] | [next] | [standalone]

#1584890 — [PATCH/RFC 2/6] PM / Wakeup: Add wakeup_source_available()

Add a helper function to find out if any wake-up sources have been
registered.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/base/power/wakeup.c | 8 ++++++++
 include/linux/pm_wakeup.h   | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index f546f8f107b06a45..1cf8320ed1a67dc4 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -232,6 +232,14 @@ void wakeup_source_unregister(struct wakeup_source *ws)
 EXPORT_SYMBOL_GPL(wakeup_source_unregister);
 
 /**
+ * wakeup_source_available - Check if any wakeup sources have been registered
+ */
+bool wakeup_source_available(void)
+{
+	return !list_empty(&wakeup_sources);
+}
+
+/**
  * device_wakeup_attach - Attach a wakeup source object to a device object.
  * @dev: Device to handle.
  * @ws: Wakeup source object to attach to @dev.
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index a3447932df1ff0a0..c5eaa8dbf27033df 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -97,6 +97,7 @@ extern void wakeup_source_add(struct wakeup_source *ws);
 extern void wakeup_source_remove(struct wakeup_source *ws);
 extern struct wakeup_source *wakeup_source_register(const char *name);
 extern void wakeup_source_unregister(struct wakeup_source *ws);
+extern bool wakeup_source_available(void);
 extern int device_wakeup_enable(struct device *dev);
 extern int device_wakeup_disable(struct device *dev);
 extern void device_set_wakeup_capable(struct device *dev, bool capable);
@@ -144,6 +145,8 @@ static inline struct wakeup_source *wakeup_source_register(const char *name)
 
 static inline void wakeup_source_unregister(struct wakeup_source *ws) {}
 
+static inline bool wakeup_source_available(void) { return false; }
+
 static inline int device_wakeup_enable(struct device *dev)
 {
 	dev->power.should_wakeup = true;
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1584891 — [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Enable support for "shallow" suspend mode, also known as "Standby" or
"Power-On Suspend".

As secondary CPU cores are taken offline, "shallow" suspend mode saves
slightly more power than "s2idle", but less than "deep" suspend mode.
However, unlike "deep" suspend mode, "shallow" suspend mode can be used
regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
an optional API in PSCI v1.0.

List the available system suspend modes:

    $ cat /sys/power/mem_sleep
    s2idle shallow [deep]

Suspend to "shallow" mode:

    $ echo shallow > /sys/power/mem_sleep
    $ echo mem > /sys/power/state

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/firmware/psci.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 493a56a4cfc4a836..13b4d50bb3577384 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -85,6 +85,7 @@ static u32 psci_function_id[PSCI_FN_MAX];
 				PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)
 
 static u32 psci_cpu_suspend_feature;
+static bool psci_suspend_mem_supported;
 
 static inline bool psci_has_ext_power_state(void)
 {
@@ -422,13 +423,36 @@ static int psci_system_suspend(unsigned long unused)
 			      __pa_symbol(cpu_resume), 0, 0);
 }
 
+static int psci_system_suspend_valid(suspend_state_t state)
+{
+	switch (state) {
+	case PM_SUSPEND_STANDBY:
+		return true;
+
+	case PM_SUSPEND_MEM:
+		return psci_suspend_mem_supported;
+
+	default:
+		return false;
+	}
+}
+
 static int psci_system_suspend_enter(suspend_state_t state)
 {
-	return cpu_suspend(0, psci_system_suspend);
+	switch (state) {
+	case PM_SUSPEND_STANDBY:
+		cpu_do_idle();
+		break;
+
+	case PM_SUSPEND_MEM:
+		return cpu_suspend(0, psci_system_suspend);
+	}
+
+	return 0;
 }
 
 static const struct platform_suspend_ops psci_suspend_ops = {
-	.valid          = suspend_valid_only_mem,
+	.valid          = psci_system_suspend_valid,
 	.enter          = psci_system_suspend_enter,
 };
 
@@ -442,7 +466,9 @@ static void __init psci_init_system_suspend(void)
 	ret = psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND));
 
 	if (ret != PSCI_RET_NOT_SUPPORTED)
-		suspend_set_ops(&psci_suspend_ops);
+		psci_suspend_mem_supported = true;
+
+	suspend_set_ops(&psci_suspend_ops);
 }
 
 static void __init psci_init_cpu_suspend(void)
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1585203 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Hi Geert,

On 20/02/17 20:33, Geert Uytterhoeven wrote:
> Enable support for "shallow" suspend mode, also known as "Standby" or
> "Power-On Suspend".
> 
> As secondary CPU cores are taken offline, "shallow" suspend mode saves
> slightly more power than "s2idle", but less than "deep" suspend mode.
> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
> an optional API in PSCI v1.0.
> 
> List the available system suspend modes:
> 
>     $ cat /sys/power/mem_sleep
>     s2idle shallow [deep]
> 
> Suspend to "shallow" mode:
> 
>     $ echo shallow > /sys/power/mem_sleep
>     $ echo mem > /sys/power/state
> 

I don't have the links to such previous attempts handy, but we have
more elegant alternative options(suspend-to-idle) and any such attempts
to hack around the PSCI will be NACKed.

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1585500 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Hi Sudeep,

On Tue, Feb 21, 2017 at 11:42 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>> Enable support for "shallow" suspend mode, also known as "Standby" or
>> "Power-On Suspend".
>>
>> As secondary CPU cores are taken offline, "shallow" suspend mode saves
>> slightly more power than "s2idle", but less than "deep" suspend mode.
>> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
>> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
>> an optional API in PSCI v1.0.
>>
>> List the available system suspend modes:
>>
>>     $ cat /sys/power/mem_sleep
>>     s2idle shallow [deep]
>>
>> Suspend to "shallow" mode:
>>
>>     $ echo shallow > /sys/power/mem_sleep
>>     $ echo mem > /sys/power/state
>>
>
> I don't have the links to such previous attempts handy, but we have

Don't worry, I did read earlier discussions about implementing shallow mode.

> more elegant alternative options(suspend-to-idle) and any such attempts
> to hack around the PSCI will be NACKed.

"s2idle" does not power down secondary CPU cores, so this is an improvement.
"deep" may not support configured wake-up sources, which is a bug.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1585527 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

On 21/02/17 16:23, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:42 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>> Enable support for "shallow" suspend mode, also known as "Standby" or
>>> "Power-On Suspend".
>>>
>>> As secondary CPU cores are taken offline, "shallow" suspend mode saves
>>> slightly more power than "s2idle", but less than "deep" suspend mode.
>>> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
>>> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
>>> an optional API in PSCI v1.0.
>>>
>>> List the available system suspend modes:
>>>
>>>     $ cat /sys/power/mem_sleep
>>>     s2idle shallow [deep]
>>>
>>> Suspend to "shallow" mode:
>>>
>>>     $ echo shallow > /sys/power/mem_sleep
>>>     $ echo mem > /sys/power/state
>>>
>>
>> I don't have the links to such previous attempts handy, but we have
> 
> Don't worry, I did read earlier discussions about implementing shallow mode.
> 

In short or just to summarize in one line, just use "freeze"(a.k.a
suspend-to-idle suspend mode)

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1585218 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

[Multipart message — attachments visible in raw view] — view raw

Hi!

> Enable support for "shallow" suspend mode, also known as "Standby" or
> "Power-On Suspend".
> 
> As secondary CPU cores are taken offline, "shallow" suspend mode saves
> slightly more power than "s2idle", but less than "deep" suspend mode.
> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
> an optional API in PSCI v1.0.

If system supports "shallow" suspend, why does not PSCI implement it?

In the past, I was told PSCI will not turn into ACPI-like mess, and
that we'll be able to fix PSCI and will not have to work around its
problems in kernel :-(.

Not your fault, Mark made those promises.
								Pavel
								
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1585231 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

On 21/02/17 11:07, Pavel Machek wrote:
> Hi!
> 
>> Enable support for "shallow" suspend mode, also known as "Standby" or
>> "Power-On Suspend".
>>
>> As secondary CPU cores are taken offline, "shallow" suspend mode saves
>> slightly more power than "s2idle", but less than "deep" suspend mode.
>> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
>> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
>> an optional API in PSCI v1.0.
> 
> If system supports "shallow" suspend, why does not PSCI implement it?
> 

Yes it can, and IIUC it already does on this platform with CPU_SUSPEND.
All it now needs is just to use existing "freeze" suspend mode in Linux.

> In the past, I was told PSCI will not turn into ACPI-like mess, and
> that we'll be able to fix PSCI and will not have to work around its
> problems in kernel :-(.

Can you be more elaborate on the mess you see on this Renesas platform.

For me, it looks like this patch is attempting to *re-implement* the
existing "suspend-to-idle" functionality. So IMO, this patch set is
creating unnecessary mess giving an illusion that PSCI specification is
broken.

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1585503 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Hi Sudeep,

On Tue, Feb 21, 2017 at 12:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 21/02/17 11:07, Pavel Machek wrote:
>>> Enable support for "shallow" suspend mode, also known as "Standby" or
>>> "Power-On Suspend".
>>>
>>> As secondary CPU cores are taken offline, "shallow" suspend mode saves
>>> slightly more power than "s2idle", but less than "deep" suspend mode.
>>> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
>>> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
>>> an optional API in PSCI v1.0.
>>
>> If system supports "shallow" suspend, why does not PSCI implement it?
>
> Yes it can, and IIUC it already does on this platform with CPU_SUSPEND.
> All it now needs is just to use existing "freeze" suspend mode in Linux.

How can Linux know if using "deep" suspend will allow to wake-up the system
according to configured wake-up sources, or not?

Note that "it will not, ever" is an accepted answer.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1585552 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

On 21/02/17 16:32, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 12:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 21/02/17 11:07, Pavel Machek wrote:
>>>> Enable support for "shallow" suspend mode, also known as "Standby" or
>>>> "Power-On Suspend".
>>>>
>>>> As secondary CPU cores are taken offline, "shallow" suspend mode saves
>>>> slightly more power than "s2idle", but less than "deep" suspend mode.
>>>> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
>>>> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
>>>> an optional API in PSCI v1.0.
>>>
>>> If system supports "shallow" suspend, why does not PSCI implement it?
>>
>> Yes it can, and IIUC it already does on this platform with CPU_SUSPEND.
>> All it now needs is just to use existing "freeze" suspend mode in Linux.
> 
> How can Linux know if using "deep" suspend will allow to wake-up the system
> according to configured wake-up sources, or not?
>

I am not sure if we have such selective configuration of wakeup source
implemented in Linux.

ACPI specification has some provisions where each device can state if it
can specify device state in each system sleeping state that can wake the
system.

DT has no mechanism today to express this relations. I had brought up
this discussion in plumbers(2015). Refer slide 7 in [0]

And the way you are trying to do that is not correct IMO especially
making it just PSCI specific.

> Note that "it will not, ever" is an accepted answer.
>

IIUC, it's not implemented today. I can't talk about future ;), but your
proposal is horrible hack.

-- 
Regards,
Sudeep

[0]
https://linuxplumbersconf.org/2015/ocw//system/presentations/3051/original/wakeup_config.pdf

[toc] | [prev] | [next] | [standalone]

#1586159 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Hi Sudeep,

On Tue, Feb 21, 2017 at 6:22 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 21/02/17 16:32, Geert Uytterhoeven wrote:
>> On Tue, Feb 21, 2017 at 12:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 21/02/17 11:07, Pavel Machek wrote:
>>>>> Enable support for "shallow" suspend mode, also known as "Standby" or
>>>>> "Power-On Suspend".
>>>>>
>>>>> As secondary CPU cores are taken offline, "shallow" suspend mode saves
>>>>> slightly more power than "s2idle", but less than "deep" suspend mode.
>>>>> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
>>>>> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
>>>>> an optional API in PSCI v1.0.
>>>>
>>>> If system supports "shallow" suspend, why does not PSCI implement it?
>>>
>>> Yes it can, and IIUC it already does on this platform with CPU_SUSPEND.
>>> All it now needs is just to use existing "freeze" suspend mode in Linux.
>>
>> How can Linux know if using "deep" suspend will allow to wake-up the system
>> according to configured wake-up sources, or not?
>
> I am not sure if we have such selective configuration of wakeup source
> implemented in Linux.
>
> ACPI specification has some provisions where each device can state if it
> can specify device state in each system sleeping state that can wake the
> system.
>
> DT has no mechanism today to express this relations. I had brought up
> this discussion in plumbers(2015). Refer slide 7 in [0]
>
> And the way you are trying to do that is not correct IMO especially
> making it just PSCI specific.
>
>> Note that "it will not, ever" is an accepted answer.
>
> IIUC, it's not implemented today. I can't talk about future ;), but your

Good, so there's no need for the DT property, and drivers/firmware/psci.c
should aways call do_cpu_idle() instead of PSCI SYSTEM_SUSPEND if any
other wake-up sources are configured?

That follows the principle of least surprise: it doesn't leave the user with
a system that won't wake up the way he configured it to wake up.

> proposal is horrible hack.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1586215 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

On 22/02/17 13:47, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 6:22 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]

>>
>> IIUC, it's not implemented today. I can't talk about future ;), but your
> 
> Good, so there's no need for the DT property, and drivers/firmware/psci.c
> should aways call do_cpu_idle() instead of PSCI SYSTEM_SUSPEND if any
> other wake-up sources are configured?
> 

No.

> That follows the principle of least surprise: it doesn't leave the user with
> a system that won't wake up the way he configured it to wake up.
> 

But he can still wake up with the "switch" so there's no surprise. He
just need to better understand his system before playing with it ;)

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1585553 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Hi,

On Tue, Feb 21, 2017 at 05:32:50PM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 21, 2017 at 12:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On 21/02/17 11:07, Pavel Machek wrote:
> >>> Enable support for "shallow" suspend mode, also known as "Standby" or
> >>> "Power-On Suspend".
> >>>
> >>> As secondary CPU cores are taken offline, "shallow" suspend mode saves
> >>> slightly more power than "s2idle", but less than "deep" suspend mode.
> >>> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
> >>> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
> >>> an optional API in PSCI v1.0.
> >>
> >> If system supports "shallow" suspend, why does not PSCI implement it?
> >
> > Yes it can, and IIUC it already does on this platform with CPU_SUSPEND.
> > All it now needs is just to use existing "freeze" suspend mode in Linux.
> 
> How can Linux know if using "deep" suspend will allow to wake-up the system
> according to configured wake-up sources, or not?

My understanding is that if a device can wake the system from
PSCI_SYSTEM_SUSPEND, it should be described in the DT as a wakeup source
[1]. So we should be able to determine the set of devices which can wake
the system from a suspend. We shouldn't assume that other devices can
(though I don't precisely what we do currently).

Otherwise, where PSCI_CPU_SUSPEND, we'd expect that most devices
(barring cpu-local timers) can wake up CPUs, and hence the system, by
raising an interrupt.

Thanks,
Mark.

[1] Documentation/devicetree/bindings/power/wakeup-source.txt

[toc] | [prev] | [next] | [standalone]

#1585582 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Hi Mark,

On Tue, Feb 21, 2017 at 6:20 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Feb 21, 2017 at 05:32:50PM +0100, Geert Uytterhoeven wrote:
>> On Tue, Feb 21, 2017 at 12:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> > On 21/02/17 11:07, Pavel Machek wrote:
>> >>> Enable support for "shallow" suspend mode, also known as "Standby" or
>> >>> "Power-On Suspend".
>> >>>
>> >>> As secondary CPU cores are taken offline, "shallow" suspend mode saves
>> >>> slightly more power than "s2idle", but less than "deep" suspend mode.
>> >>> However, unlike "deep" suspend mode, "shallow" suspend mode can be used
>> >>> regardless of the presence of support for PSCI_SYSTEM_SUSPEND, which is
>> >>> an optional API in PSCI v1.0.
>> >>
>> >> If system supports "shallow" suspend, why does not PSCI implement it?
>> >
>> > Yes it can, and IIUC it already does on this platform with CPU_SUSPEND.
>> > All it now needs is just to use existing "freeze" suspend mode in Linux.
>>
>> How can Linux know if using "deep" suspend will allow to wake-up the system
>> according to configured wake-up sources, or not?
>
> My understanding is that if a device can wake the system from
> PSCI_SYSTEM_SUSPEND, it should be described in the DT as a wakeup source
> [1]. So we should be able to determine the set of devices which can wake
> the system from a suspend. We shouldn't assume that other devices can
> (though I don't precisely what we do currently).
>
> Otherwise, where PSCI_CPU_SUSPEND, we'd expect that most devices
> (barring cpu-local timers) can wake up CPUs, and hence the system, by
> raising an interrupt.

> [1] Documentation/devicetree/bindings/power/wakeup-source.txt

"wakeup-source" in DT is used as a mix of hardware description and software
policy.  E.g. some keys on a keyboard may have it, others don't, while there's
not always a technical reason for that.

Also, it doesn't specify from which suspend state it can wake-up.

On top of that, the Linux PM subsystem allows to configure wakeup by writing
"enabled" to a device's "wakeup" file in sysfs.  Or you can use ethtool for
Wake-on-LAN.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1585586 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Hi,

On Tue, Feb 21, 2017 at 07:06:04PM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 21, 2017 at 6:20 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Feb 21, 2017 at 05:32:50PM +0100, Geert Uytterhoeven wrote:

> >> How can Linux know if using "deep" suspend will allow to wake-up the system
> >> according to configured wake-up sources, or not?
> >
> > My understanding is that if a device can wake the system from
> > PSCI_SYSTEM_SUSPEND, it should be described in the DT as a wakeup source
> > [1]. So we should be able to determine the set of devices which can wake
> > the system from a suspend. We shouldn't assume that other devices can
> > (though I don't precisely what we do currently).
> >
> > Otherwise, where PSCI_CPU_SUSPEND, we'd expect that most devices
> > (barring cpu-local timers) can wake up CPUs, and hence the system, by
> > raising an interrupt.
> 
> > [1] Documentation/devicetree/bindings/power/wakeup-source.txt
> 
> "wakeup-source" in DT is used as a mix of hardware description and software
> policy.  E.g. some keys on a keyboard may have it, others don't, while there's
> not always a technical reason for that.
> 
> Also, it doesn't specify from which suspend state it can wake-up.

Joy.

If we need to do something here, we should clarify the semantics of
wakeup-source and/or introduce a property which is explicitly for the
purpose of expressing HW capability to wake up from a specific power
state.

> On top of that, the Linux PM subsystem allows to configure wakeup by writing
> "enabled" to a device's "wakeup" file in sysfs.  Or you can use ethtool for
> Wake-on-LAN.

Sure; userspace can always do something silly here.

As I mentioned in my other reply, we could/should add an interface to
allow userspace to determine if it has a guaranteed wakeup, which would
allow us to do the right thing.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

#1585597 — Re: [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

Hi Mark,

On Tue, Feb 21, 2017 at 7:18 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On top of that, the Linux PM subsystem allows to configure wakeup by writing
>> "enabled" to a device's "wakeup" file in sysfs.  Or you can use ethtool for
>> Wake-on-LAN.
>
> Sure; userspace can always do something silly here.

Not that silly: you can wake up using these sources, but not necessarily from
all states.

> As I mentioned in my other reply, we could/should add an interface to
> allow userspace to determine if it has a guaranteed wakeup, which would
> allow us to do the right thing.

Right.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1584893 — [PATCH/RFC 1/6] alarmtimer: Postpone wake-up source registration until really available

Currently the alarmtimer registers a wake-up source unconditionally,
regardless of the system having a (wake-up capable) RTC or not.
To fix this, postpone registration until a wake-up capable RTC device is
added.

After this, the alarmtimer no longer shows up in
/sys/kernel/debug/wakeup_sources, unless it is available for real.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 kernel/time/alarmtimer.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index e6dc9a538efa2116..5e0ce78607da5b5d 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -82,6 +82,7 @@ static int alarmtimer_rtc_add_device(struct device *dev,
 {
 	unsigned long flags;
 	struct rtc_device *rtc = to_rtc_device(dev);
+	struct wakeup_source *__ws;
 
 	if (rtcdev)
 		return -EBUSY;
@@ -91,13 +92,20 @@ static int alarmtimer_rtc_add_device(struct device *dev,
 	if (!device_may_wakeup(rtc->dev.parent))
 		return -1;
 
+	__ws = wakeup_source_register("alarmtimer");
+
 	spin_lock_irqsave(&rtcdev_lock, flags);
 	if (!rtcdev) {
 		rtcdev = rtc;
 		/* hold a reference so it doesn't go away */
 		get_device(dev);
+		ws = __ws;
+		__ws = NULL;
 	}
 	spin_unlock_irqrestore(&rtcdev_lock, flags);
+
+	wakeup_source_unregister(__ws);
+
 	return 0;
 }
 
@@ -908,7 +916,6 @@ static int __init alarmtimer_init(void)
 		error = PTR_ERR(pdev);
 		goto out_drv;
 	}
-	ws = wakeup_source_register("alarmtimer");
 	return 0;
 
 out_drv:
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1584894 — [PATCH/RFC 6/6] arm64: dts: r8a7796: Fix non-PMIC wake-up sources

The PSCI firmware on boards equipped with an R-Car M3-W SoC implements
the PSCI SYSTEM_SUSPEND operation by cutting power to the SoC.  Hence
the only possibly wake-up sources are the ones connected to the PMIC,
unless the "arm,psci-system-suspend-is-power-down" property is
specified.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 02febb434d1ca028..a11f030e97902e1c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -31,6 +31,7 @@
 	psci {
 		compatible = "arm,psci-0.2";
 		method = "smc";
+		arm,psci-system-suspend-is-power-down;
 	};
 
 	cpus {
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1584895 — [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

Nothing in the PSCI specification requires the SoC to remain powered and
to support wake-up sources when suspended using SYSTEM_SUSPEND.
If the firmware implements the PSCI SYSTEM_SUSPEND operation by cutting
power to the SoC, the only possibly wake-up sources are thus the ones
connected to the PMIC.

Document and add support for an "arm,psci-system-suspend-is-power-down"
DT property, so Linux uses a different suspend method when other wake-up
sources (e.g. wake on LAN, UART or GPIO) are enabled.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 Documentation/devicetree/bindings/arm/psci.txt | 11 +++++++++++
 drivers/firmware/psci.c                        | 13 ++++++++++---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index a2c4f1d524929bb7..16e390ecb7531028 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -68,6 +68,17 @@ state nodes, as per bindings in [1]) must specify the following properties:
 		Definition: power_state parameter to pass to the PSCI
 			    suspend call.
 
+ - arm,psci-system-suspend-is-power-down
+		Nothing in the PSCI specification requires the SoC to remain
+		powered and to support wake-up sources when suspended using
+		SYSTEM_SUSPEND.
+		If your firmware implements the PSCI SYSTEM_SUSPEND operation
+		by cutting power to the SoC, the only possibly wake-up sources
+		are thus the ones connected to the PMIC.  In such case you
+		should specify this property, so the operating system is aware
+		it should use a different suspend method when other wake-up
+		sources (e.g. wake on LAN, UART or GPIO) are enabled.
+
 Example:
 
 Case 1: PSCI v0.1 only.
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 13b4d50bb3577384..0a74c23fd5fe043e 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -20,6 +20,7 @@
 #include <linux/linkage.h>
 #include <linux/of.h>
 #include <linux/pm.h>
+#include <linux/pm_wakeup.h>
 #include <linux/printk.h>
 #include <linux/psci.h>
 #include <linux/reboot.h>
@@ -86,6 +87,7 @@ static u32 psci_function_id[PSCI_FN_MAX];
 
 static u32 psci_cpu_suspend_feature;
 static bool psci_suspend_mem_supported;
+static bool psci_system_suspend_is_power_down;
 
 static inline bool psci_has_ext_power_state(void)
 {
@@ -440,12 +442,14 @@ static int psci_system_suspend_valid(suspend_state_t state)
 static int psci_system_suspend_enter(suspend_state_t state)
 {
 	switch (state) {
+	case PM_SUSPEND_MEM:
+		if (!psci_system_suspend_is_power_down ||
+		    !wakeup_source_available())
+			return cpu_suspend(0, psci_system_suspend);
+		/* fall through */
 	case PM_SUSPEND_STANDBY:
 		cpu_do_idle();
 		break;
-
-	case PM_SUSPEND_MEM:
-		return cpu_suspend(0, psci_system_suspend);
 	}
 
 	return 0;
@@ -596,6 +600,9 @@ static int __init psci_0_2_init(struct device_node *np)
 	 */
 	err = psci_probe();
 
+	psci_system_suspend_is_power_down = of_property_read_bool(np,
+		"arm,psci-system-suspend-is-power-down");
+
 out_put_node:
 	of_node_put(np);
 	return err;
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1585206 — Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

On 20/02/17 20:33, Geert Uytterhoeven wrote:
> Nothing in the PSCI specification requires the SoC to remain powered and
> to support wake-up sources when suspended using SYSTEM_SUSPEND.
> If the firmware implements the PSCI SYSTEM_SUSPEND operation by cutting
> power to the SoC, the only possibly wake-up sources are thus the ones
> connected to the PMIC.
> 
> Document and add support for an "arm,psci-system-suspend-is-power-down"
> DT property, so Linux uses a different suspend method when other wake-up
> sources (e.g. wake on LAN, UART or GPIO) are enabled.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  Documentation/devicetree/bindings/arm/psci.txt | 11 +++++++++++
>  drivers/firmware/psci.c                        | 13 ++++++++++---
>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> index a2c4f1d524929bb7..16e390ecb7531028 100644
> --- a/Documentation/devicetree/bindings/arm/psci.txt
> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> @@ -68,6 +68,17 @@ state nodes, as per bindings in [1]) must specify the following properties:
>  		Definition: power_state parameter to pass to the PSCI
>  			    suspend call.
>  
> + - arm,psci-system-suspend-is-power-down
> +		Nothing in the PSCI specification requires the SoC to remain
> +		powered and to support wake-up sources when suspended using
> +		SYSTEM_SUSPEND.

Again, yes SoC can be powered down but you give no reasons why this is
useful other than help you to hack around to implement suspend_ops. As
suggested please try using freeze_ops.

After commit a94e502c22b6 ("cpuidle: dt: assign ->enter_freeze to same
as ->enter callback function"), you can enter suspend-to-idle(a.k.a
freeze state) on all platforms using ARM DT cpuidle driver.

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web