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

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

[Geert Uytterhoeven]

	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

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

[Geert Uytterhoeven]

	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 at 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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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 at 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

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

[Geert Uytterhoeven]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Pavel Machek]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170221/96d9dd2b/attachment.sig>

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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
--
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/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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 at 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

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

[Geert Uytterhoeven]

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

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

[Mark Rutland]

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

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

[Mark Rutland]

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

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

[Mark Rutland]

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

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

[Mark Rutland]

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-5wv7dgnIgG8@public.gmane.org> 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
--
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/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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 at 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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

Hi Mark,

On Tue, Feb 21, 2017 at 6:20 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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-5wv7dgnIgG8@public.gmane.org> 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-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
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/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

[Mark Rutland]

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.

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

[Mark Rutland]

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.

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

[Mark Rutland]

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.

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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 at 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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

On 21/02/17 16:32, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 12:14 PM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> 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
--
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/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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 at 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

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

[Geert Uytterhoeven]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Sudeep Holla]

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

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

[Sudeep Holla]

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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 11:50 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> 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

This is useful to support other wake-up sources. Linux has a standardized
way to handle wake-up sources, which may be circumvented by calling PSCI
SYSTEM_SUSPEND.

> suggested please try using freeze_ops.

Freezing the system works, but requires manual configurarion.
This should be done automatically.

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

This should be used automatically if the system can't wake-up from
suspend-to-RAM using the configured wake-up sources.

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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 11:50 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> 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

This is useful to support other wake-up sources. Linux has a standardized
way to handle wake-up sources, which may be circumvented by calling PSCI
SYSTEM_SUSPEND.

> suggested please try using freeze_ops.

Freezing the system works, but requires manual configurarion.
This should be done automatically.

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

This should be used automatically if the system can't wake-up from
suspend-to-RAM using the configured wake-up sources.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 11:50 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> 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

This is useful to support other wake-up sources. Linux has a standardized
way to handle wake-up sources, which may be circumvented by calling PSCI
SYSTEM_SUSPEND.

> suggested please try using freeze_ops.

Freezing the system works, but requires manual configurarion.
This should be done automatically.

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

This should be used automatically if the system can't wake-up from
suspend-to-RAM using the configured wake-up sources.

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

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

[Sudeep Holla]

Hi Geert,

On 21/02/17 16:36, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:50 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> 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
> 
> This is useful to support other wake-up sources. Linux has a standardized
> way to handle wake-up sources, which may be circumvented by calling PSCI
> SYSTEM_SUSPEND.
> 
>> suggested please try using freeze_ops.
> 
> Freezing the system works, but requires manual configurarion.
> This should be done automatically.
> 

What sort of manual configuration ? I am just asking to understand you
setup better.

>> 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.
> 
> This should be used automatically if the system can't wake-up from
> suspend-to-RAM using the configured wake-up sources.
> 

Yes.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

Hi Geert,

On 21/02/17 16:36, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:50 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> 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
> 
> This is useful to support other wake-up sources. Linux has a standardized
> way to handle wake-up sources, which may be circumvented by calling PSCI
> SYSTEM_SUSPEND.
> 
>> suggested please try using freeze_ops.
> 
> Freezing the system works, but requires manual configurarion.
> This should be done automatically.
> 

What sort of manual configuration ? I am just asking to understand you
setup better.

>> 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.
> 
> This should be used automatically if the system can't wake-up from
> suspend-to-RAM using the configured wake-up sources.
> 

Yes.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

Hi Geert,

On 21/02/17 16:36, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:50 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> 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
> 
> This is useful to support other wake-up sources. Linux has a standardized
> way to handle wake-up sources, which may be circumvented by calling PSCI
> SYSTEM_SUSPEND.
> 
>> suggested please try using freeze_ops.
> 
> Freezing the system works, but requires manual configurarion.
> This should be done automatically.
> 

What sort of manual configuration ? I am just asking to understand you
setup better.

>> 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.
> 
> This should be used automatically if the system can't wake-up from
> suspend-to-RAM using the configured wake-up sources.
> 

Yes.

-- 
Regards,
Sudeep

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

On Mon 2017-02-20 21:33:27, 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.

Should we make PSCI return that information? (At least in next
specification version?)

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Pavel Machek]

On Mon 2017-02-20 21:33:27, 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.

Should we make PSCI return that information? (At least in next
specification version?)

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170221/5320f29d/attachment.sig>

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

[Geert Uytterhoeven]

Hi Pavel,

On Tue, Feb 21, 2017 at 12:07 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2017-02-20 21:33:27, 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.
>
> Should we make PSCI return that information? (At least in next
> specification version?)

That's a possible solution.

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

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

[Geert Uytterhoeven]

Hi Pavel,

On Tue, Feb 21, 2017 at 12:07 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2017-02-20 21:33:27, 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.
>
> Should we make PSCI return that information? (At least in next
> specification version?)

That's a possible solution.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Pavel,

On Tue, Feb 21, 2017 at 12:07 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2017-02-20 21:33:27, 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.
>
> Should we make PSCI return that information? (At least in next
> specification version?)

That's a possible solution.

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

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

[Mark Rutland]

On Tue, Feb 21, 2017 at 12:07:30PM +0100, Pavel Machek wrote:
> On Mon 2017-02-20 21:33:27, 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.
> 
> Should we make PSCI return that information? (At least in next
> specification version?)

Largely, this is somewhat ill-defined, so it's not something that can be
easily (or correctly) described by a limited firmware call interface.

I believe that the correct way to describe this is to describe the
wakeup capabilities on devices. Both ACPI and DT have mechanisms for
that today, though it seems that there is confusion as to precisely how
to use them.

Thanks,
Mark.

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

[Mark Rutland]

On Tue, Feb 21, 2017 at 12:07:30PM +0100, Pavel Machek wrote:
> On Mon 2017-02-20 21:33:27, 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.
> 
> Should we make PSCI return that information? (At least in next
> specification version?)

Largely, this is somewhat ill-defined, so it's not something that can be
easily (or correctly) described by a limited firmware call interface.

I believe that the correct way to describe this is to describe the
wakeup capabilities on devices. Both ACPI and DT have mechanisms for
that today, though it seems that there is confusion as to precisely how
to use them.

Thanks,
Mark.

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

[Mark Rutland]

Hi,

On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
> + - 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.
> +

My understanding is that we already have sufficient information here,
encoded in the wakeup-source property on devices. If DTs have
insufficient information today, we should add those as necessary rather
than modifying the PSCI node.

As Sudeep mentioned, we already have systems which fall into this
category, and those do not require us to do anything special.

As such, I do not believe this is the correct way to describe the
situation.

[...]

> @@ -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 */

I don't believe that this is the correct place to handle this.

The wakeup_source_available() check *might* be ok, though even with that
I'd rather we rejected the request rather than trying to fall back to a
PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.

I can imagine that there are cases where the wakeup source is completely
external and invisible to Linux (e.g. a power button that has no
programming interface, and isn't desscribed at all). In that case, even
the wakeup_source_available() check might be too much. :/

What we could/should do is expose to userspace which suspend cases a
device can wake up the system from and/or whether a wakeup source is
suitable configured for a state currently. That way userspace can
determine whether it is gauranteed to be woken.

Thanks,
Mark.

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

[Mark Rutland]

Hi,

On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
> + - 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.
> +

My understanding is that we already have sufficient information here,
encoded in the wakeup-source property on devices. If DTs have
insufficient information today, we should add those as necessary rather
than modifying the PSCI node.

As Sudeep mentioned, we already have systems which fall into this
category, and those do not require us to do anything special.

As such, I do not believe this is the correct way to describe the
situation.

[...]

> @@ -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 */

I don't believe that this is the correct place to handle this.

The wakeup_source_available() check *might* be ok, though even with that
I'd rather we rejected the request rather than trying to fall back to a
PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.

I can imagine that there are cases where the wakeup source is completely
external and invisible to Linux (e.g. a power button that has no
programming interface, and isn't desscribed at all). In that case, even
the wakeup_source_available() check might be too much. :/

What we could/should do is expose to userspace which suspend cases a
device can wake up the system from and/or whether a wakeup source is
suitable configured for a state currently. That way userspace can
determine whether it is gauranteed to be woken.

Thanks,
Mark.

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

[Geert Uytterhoeven]

Hi Mark,

On Tue, Feb 21, 2017 at 6:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
>> @@ -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 */
>
> I don't believe that this is the correct place to handle this.
>
> The wakeup_source_available() check *might* be ok, though even with that
> I'd rather we rejected the request rather than trying to fall back to a
> PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.

If we reject the request here, I think the PM core has to be modified to
try again using a shallower state. Note that it would be better to reject
the state in the .valid() callback instead of in .enter().

You also have to consider this is dynamic not static.
I.e. the availability of other wake-up sources may change at runtime (cfr.
the "wakeup" files in sysfs). Currently pm_sleep_states[] (which controls
which states are available) is initialized from suspend_set_ops(), and not
changed later.

Perhaps pm_sleep_states[] should be updated every time the wakeup_sources
list is changed?

> I can imagine that there are cases where the wakeup source is completely
> external and invisible to Linux (e.g. a power button that has no
> programming interface, and isn't desscribed at all). In that case, even
> the wakeup_source_available() check might be too much. :/

You mean the wakeup source that actually wakes up the system from PSCI
SYSTEM_SUSPEND? On Renesas boards, that's a switch wired to the PMIC,
and currently not described in DT.  Describing it in DT could indeed interfere
with wakeup_source_available() :-(

> What we could/should do is expose to userspace which suspend cases a
> device can wake up the system from and/or whether a wakeup source is
> suitable configured for a state currently. That way userspace can
> determine whether it is gauranteed to be woken.

Right.  And that information should come from DT?

Thanks!

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

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

[Geert Uytterhoeven]

Hi Mark,

On Tue, Feb 21, 2017 at 6:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
>> @@ -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 */
>
> I don't believe that this is the correct place to handle this.
>
> The wakeup_source_available() check *might* be ok, though even with that
> I'd rather we rejected the request rather than trying to fall back to a
> PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.

If we reject the request here, I think the PM core has to be modified to
try again using a shallower state. Note that it would be better to reject
the state in the .valid() callback instead of in .enter().

You also have to consider this is dynamic not static.
I.e. the availability of other wake-up sources may change at runtime (cfr.
the "wakeup" files in sysfs). Currently pm_sleep_states[] (which controls
which states are available) is initialized from suspend_set_ops(), and not
changed later.

Perhaps pm_sleep_states[] should be updated every time the wakeup_sources
list is changed?

> I can imagine that there are cases where the wakeup source is completely
> external and invisible to Linux (e.g. a power button that has no
> programming interface, and isn't desscribed at all). In that case, even
> the wakeup_source_available() check might be too much. :/

You mean the wakeup source that actually wakes up the system from PSCI
SYSTEM_SUSPEND? On Renesas boards, that's a switch wired to the PMIC,
and currently not described in DT.  Describing it in DT could indeed interfere
with wakeup_source_available() :-(

> What we could/should do is expose to userspace which suspend cases a
> device can wake up the system from and/or whether a wakeup source is
> suitable configured for a state currently. That way userspace can
> determine whether it is gauranteed to be woken.

Right.  And that information should come from DT?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Mark,

On Tue, Feb 21, 2017 at 6:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
>> @@ -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 */
>
> I don't believe that this is the correct place to handle this.
>
> The wakeup_source_available() check *might* be ok, though even with that
> I'd rather we rejected the request rather than trying to fall back to a
> PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.

If we reject the request here, I think the PM core has to be modified to
try again using a shallower state. Note that it would be better to reject
the state in the .valid() callback instead of in .enter().

You also have to consider this is dynamic not static.
I.e. the availability of other wake-up sources may change at runtime (cfr.
the "wakeup" files in sysfs). Currently pm_sleep_states[] (which controls
which states are available) is initialized from suspend_set_ops(), and not
changed later.

Perhaps pm_sleep_states[] should be updated every time the wakeup_sources
list is changed?

> I can imagine that there are cases where the wakeup source is completely
> external and invisible to Linux (e.g. a power button that has no
> programming interface, and isn't desscribed at all). In that case, even
> the wakeup_source_available() check might be too much. :/

You mean the wakeup source that actually wakes up the system from PSCI
SYSTEM_SUSPEND? On Renesas boards, that's a switch wired to the PMIC,
and currently not described in DT.  Describing it in DT could indeed interfere
with wakeup_source_available() :-(

> What we could/should do is expose to userspace which suspend cases a
> device can wake up the system from and/or whether a wakeup source is
> suitable configured for a state currently. That way userspace can
> determine whether it is gauranteed to be woken.

Right.  And that information should come from DT?

Thanks!

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

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 3:05 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Mark,
>
> On Tue, Feb 21, 2017 at 6:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
>>> @@ -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 */
>>
>> I don't believe that this is the correct place to handle this.
>>
>> The wakeup_source_available() check *might* be ok, though even with that
>> I'd rather we rejected the request rather than trying to fall back to a
>> PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.
>
> If we reject the request here, I think the PM core has to be modified to
> try again using a shallower state. Note that it would be better to reject
> the state in the .valid() callback instead of in .enter().
>
> You also have to consider this is dynamic not static.
> I.e. the availability of other wake-up sources may change at runtime (cfr.
> the "wakeup" files in sysfs). Currently pm_sleep_states[] (which controls
> which states are available) is initialized from suspend_set_ops(), and not
> changed later.
>
> Perhaps pm_sleep_states[] should be updated every time the wakeup_sources
> list is changed?

No, the definitions of sleep states *are* static.  They have to be, or
user space won't know what sleep state it is asking for.

And, as I said in my last reply to Sudeep, the list of possible wakeup
devices for the given state is part of that definition.  The sysfs
"wakeup" interface is on top of that, not the other way around (which
seems seems to be what you would want).

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 3:05 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Mark,
>
> On Tue, Feb 21, 2017 at 6:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
>>> @@ -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 */
>>
>> I don't believe that this is the correct place to handle this.
>>
>> The wakeup_source_available() check *might* be ok, though even with that
>> I'd rather we rejected the request rather than trying to fall back to a
>> PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.
>
> If we reject the request here, I think the PM core has to be modified to
> try again using a shallower state. Note that it would be better to reject
> the state in the .valid() callback instead of in .enter().
>
> You also have to consider this is dynamic not static.
> I.e. the availability of other wake-up sources may change at runtime (cfr.
> the "wakeup" files in sysfs). Currently pm_sleep_states[] (which controls
> which states are available) is initialized from suspend_set_ops(), and not
> changed later.
>
> Perhaps pm_sleep_states[] should be updated every time the wakeup_sources
> list is changed?

No, the definitions of sleep states *are* static.  They have to be, or
user space won't know what sleep state it is asking for.

And, as I said in my last reply to Sudeep, the list of possible wakeup
devices for the given state is part of that definition.  The sysfs
"wakeup" interface is on top of that, not the other way around (which
seems seems to be what you would want).

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 3:05 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Mark,
>
> On Tue, Feb 21, 2017 at 6:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
>>> @@ -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 */
>>
>> I don't believe that this is the correct place to handle this.
>>
>> The wakeup_source_available() check *might* be ok, though even with that
>> I'd rather we rejected the request rather than trying to fall back to a
>> PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.
>
> If we reject the request here, I think the PM core has to be modified to
> try again using a shallower state. Note that it would be better to reject
> the state in the .valid() callback instead of in .enter().
>
> You also have to consider this is dynamic not static.
> I.e. the availability of other wake-up sources may change at runtime (cfr.
> the "wakeup" files in sysfs). Currently pm_sleep_states[] (which controls
> which states are available) is initialized from suspend_set_ops(), and not
> changed later.
>
> Perhaps pm_sleep_states[] should be updated every time the wakeup_sources
> list is changed?

No, the definitions of sleep states *are* static.  They have to be, or
user space won't know what sleep state it is asking for.

And, as I said in my last reply to Sudeep, the list of possible wakeup
devices for the given state is part of that definition.  The sysfs
"wakeup" interface is on top of that, not the other way around (which
seems seems to be what you would want).

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 3:05 PM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi Mark,
>
> On Tue, Feb 21, 2017 at 6:48 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
>> On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote:
>>> @@ -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 */
>>
>> I don't believe that this is the correct place to handle this.
>>
>> The wakeup_source_available() check *might* be ok, though even with that
>> I'd rather we rejected the request rather than trying to fall back to a
>> PSCI_CPU_SUSPEND. Otherwise we have a potential silent power regression.
>
> If we reject the request here, I think the PM core has to be modified to
> try again using a shallower state. Note that it would be better to reject
> the state in the .valid() callback instead of in .enter().
>
> You also have to consider this is dynamic not static.
> I.e. the availability of other wake-up sources may change at runtime (cfr.
> the "wakeup" files in sysfs). Currently pm_sleep_states[] (which controls
> which states are available) is initialized from suspend_set_ops(), and not
> changed later.
>
> Perhaps pm_sleep_states[] should be updated every time the wakeup_sources
> list is changed?

No, the definitions of sleep states *are* static.  They have to be, or
user space won't know what sleep state it is asking for.

And, as I said in my last reply to Sudeep, the list of possible wakeup
devices for the given state is part of that definition.  The sysfs
"wakeup" interface is on top of that, not the other way around (which
seems seems to be what you would want).

Thanks,
Rafael
--
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

[PATCH/RFC 5/6] arm64: dts: r8a7795: Fix non-PMIC wake-up sources

[Geert Uytterhoeven]

The PSCI firmware on boards equipped with an R-Car H3 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/r8a7795.dtsi | 1 +
 1 file changed, 1 insertion(+)

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

[PATCH/RFC 5/6] arm64: dts: r8a7795: Fix non-PMIC wake-up sources

[Geert Uytterhoeven]

The PSCI firmware on boards equipped with an R-Car H3 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/r8a7795.dtsi | 1 +
 1 file changed, 1 insertion(+)

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

[PATCH/RFC 5/6] arm64: dts: r8a7795: Fix non-PMIC wake-up sources

[Geert Uytterhoeven]

The PSCI firmware on boards equipped with an R-Car H3 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-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 1 +
 1 file changed, 1 insertion(+)

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

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Sudeep Holla]

Hi Geert,

On 20/02/17 20:33, Geert Uytterhoeven wrote:
> 	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.
> 

OK, but I don't see any issue with that. That's exactly how it works on
ARM Juno platform. The SoC is powered down.

> 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

NACK, you don't need any such properties.

> 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:
> 

Have you explored suspend-to-idle instead ? It looks like thats exactly
what you are doing in this patch set. You also get low latency for free
as it just enters the deepest idle state on all CPUs instead of
hotplugging out all the secondaries.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

Hi Geert,

On 20/02/17 20:33, Geert Uytterhoeven wrote:
> 	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.
> 

OK, but I don't see any issue with that. That's exactly how it works on
ARM Juno platform. The SoC is powered down.

> 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

NACK, you don't need any such properties.

> 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:
> 

Have you explored suspend-to-idle instead ? It looks like thats exactly
what you are doing in this patch set. You also get low latency for free
as it just enters the deepest idle state on all CPUs instead of
hotplugging out all the secondaries.

-- 
Regards,
Sudeep

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

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>> 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.
>
> OK, but I don't see any issue with that. That's exactly how it works on

How do you use other wake-up sources, like wake on LAN, UART or GPIO?

> ARM Juno platform. The SoC is powered down.

Good to hear this is not limited to Renesas platforms, so there's a common
problem to solve.

>> 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
>
> NACK, you don't need any such properties.

If this is true for all PSCI platforms, there's indeed no need for such a
property, and drivers/firmware/psci.c should default to this case.

>> 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:
>
> Have you explored suspend-to-idle instead ? It looks like thats exactly
> what you are doing in this patch set. You also get low latency for free
> as it just enters the deepest idle state on all CPUs instead of
> hotplugging out all the secondaries.

Yes, cfr. "s2idle" above.
The user can specify to use "s2idle" manually:

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

However, how to handle this automatically, e.g. by a distro?
On most other platforms, userspace can just do e.g.

    ethtool -s eth0 wol g

to enable wake-on-LAN, and suspend to the deepest supported state using:

    echo mem > /sys/power/state

On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
make sure to configure to use "s2idle" (or "shallow) instead, else the
configured wake-up sources won't work.
I want Linux to handle this automatically.

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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>> 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.
>
> OK, but I don't see any issue with that. That's exactly how it works on

How do you use other wake-up sources, like wake on LAN, UART or GPIO?

> ARM Juno platform. The SoC is powered down.

Good to hear this is not limited to Renesas platforms, so there's a common
problem to solve.

>> 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
>
> NACK, you don't need any such properties.

If this is true for all PSCI platforms, there's indeed no need for such a
property, and drivers/firmware/psci.c should default to this case.

>> 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:
>
> Have you explored suspend-to-idle instead ? It looks like thats exactly
> what you are doing in this patch set. You also get low latency for free
> as it just enters the deepest idle state on all CPUs instead of
> hotplugging out all the secondaries.

Yes, cfr. "s2idle" above.
The user can specify to use "s2idle" manually:

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

However, how to handle this automatically, e.g. by a distro?
On most other platforms, userspace can just do e.g.

    ethtool -s eth0 wol g

to enable wake-on-LAN, and suspend to the deepest supported state using:

    echo mem > /sys/power/state

On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
make sure to configure to use "s2idle" (or "shallow) instead, else the
configured wake-up sources won't work.
I want Linux to handle this automatically.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>> 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.
>
> OK, but I don't see any issue with that. That's exactly how it works on

How do you use other wake-up sources, like wake on LAN, UART or GPIO?

> ARM Juno platform. The SoC is powered down.

Good to hear this is not limited to Renesas platforms, so there's a common
problem to solve.

>> 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
>
> NACK, you don't need any such properties.

If this is true for all PSCI platforms, there's indeed no need for such a
property, and drivers/firmware/psci.c should default to this case.

>> 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:
>
> Have you explored suspend-to-idle instead ? It looks like thats exactly
> what you are doing in this patch set. You also get low latency for free
> as it just enters the deepest idle state on all CPUs instead of
> hotplugging out all the secondaries.

Yes, cfr. "s2idle" above.
The user can specify to use "s2idle" manually:

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

However, how to handle this automatically, e.g. by a distro?
On most other platforms, userspace can just do e.g.

    ethtool -s eth0 wol g

to enable wake-on-LAN, and suspend to the deepest supported state using:

    echo mem > /sys/power/state

On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
make sure to configure to use "s2idle" (or "shallow) instead, else the
configured wake-up sources won't work.
I want Linux to handle this automatically.

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

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

[Sudeep Holla]

Hi Geert,

On 21/02/17 16:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>> 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.
>>
>> OK, but I don't see any issue with that. That's exactly how it works on
> 
> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
> 

>From wakeup source configuration/management perspective, s2ram and
s2idle are exactly same.

>> ARM Juno platform. The SoC is powered down.
> 
> Good to hear this is not limited to Renesas platforms, so there's a common
> problem to solve.
> 

No, there's no problem to solve. Firmware should enter deepest sleep
state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

>>> 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
>>
>> NACK, you don't need any such properties.
> 
> If this is true for all PSCI platforms, there's indeed no need for such a
> property, and drivers/firmware/psci.c should default to this case.
> 

Cool.

>>> 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:
>>
>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>> what you are doing in this patch set. You also get low latency for free
>> as it just enters the deepest idle state on all CPUs instead of
>> hotplugging out all the secondaries.
> 
> Yes, cfr. "s2idle" above.
> The user can specify to use "s2idle" manually:
> 
>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
> 

This looks like custom file for me.
IIUC, the standard sysfs file for the system PM state is:
	/sys/power/state
1. s2ram:
	$ echo mem > /sys/power/state
2. s2idle
	$ echo freeze > /sys/power/state

> However, how to handle this automatically, e.g. by a distro?

As above

> On most other platforms, userspace can just do e.g.
> 
>     ethtool -s eth0 wol g
> 

That should work.

> to enable wake-on-LAN, and suspend to the deepest supported state using:
> 
>     echo mem > /sys/power/state
> 

This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
can't wakeup if it's powered down, then it should not use that state
to implement SYSTEM_SUSPEND in PSCI firmware or just return the
SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
next available state to enter.

Just botching whatever shallow state you can enter on a particular SoC
into standard "mem" state sounds *horrible* to me.

> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
> make sure to configure to use "s2idle" (or "shallow) instead, else the
> configured wake-up sources won't work.

That's perfect. I was worried that user-space is not doing that. So to
summarize, PSCI firmware either:
1. enters a sane and resumable state in SYSTEM_SUSPEND api
or
2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
   in Linux to enter the deepest idle state.

You literally need no extra work to enter this "freeze" state if the
CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
in this "s2idle" you are referring so far.
Just start with:

	$ cat /sys/power/state

and you should see "freeze" there, if not that's the first thing to
check provided the platform has cpuidle working.

Hope this helps.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

Hi Geert,

On 21/02/17 16:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>> 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.
>>
>> OK, but I don't see any issue with that. That's exactly how it works on
> 
> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
> 

>From wakeup source configuration/management perspective, s2ram and
s2idle are exactly same.

>> ARM Juno platform. The SoC is powered down.
> 
> Good to hear this is not limited to Renesas platforms, so there's a common
> problem to solve.
> 

No, there's no problem to solve. Firmware should enter deepest sleep
state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

>>> 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
>>
>> NACK, you don't need any such properties.
> 
> If this is true for all PSCI platforms, there's indeed no need for such a
> property, and drivers/firmware/psci.c should default to this case.
> 

Cool.

>>> 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:
>>
>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>> what you are doing in this patch set. You also get low latency for free
>> as it just enters the deepest idle state on all CPUs instead of
>> hotplugging out all the secondaries.
> 
> Yes, cfr. "s2idle" above.
> The user can specify to use "s2idle" manually:
> 
>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
> 

This looks like custom file for me.
IIUC, the standard sysfs file for the system PM state is:
	/sys/power/state
1. s2ram:
	$ echo mem > /sys/power/state
2. s2idle
	$ echo freeze > /sys/power/state

> However, how to handle this automatically, e.g. by a distro?

As above

> On most other platforms, userspace can just do e.g.
> 
>     ethtool -s eth0 wol g
> 

That should work.

> to enable wake-on-LAN, and suspend to the deepest supported state using:
> 
>     echo mem > /sys/power/state
> 

This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
can't wakeup if it's powered down, then it should not use that state
to implement SYSTEM_SUSPEND in PSCI firmware or just return the
SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
next available state to enter.

Just botching whatever shallow state you can enter on a particular SoC
into standard "mem" state sounds *horrible* to me.

> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
> make sure to configure to use "s2idle" (or "shallow) instead, else the
> configured wake-up sources won't work.

That's perfect. I was worried that user-space is not doing that. So to
summarize, PSCI firmware either:
1. enters a sane and resumable state in SYSTEM_SUSPEND api
or
2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
   in Linux to enter the deepest idle state.

You literally need no extra work to enter this "freeze" state if the
CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
in this "s2idle" you are referring so far.
Just start with:

	$ cat /sys/power/state

and you should see "freeze" there, if not that's the first thing to
check provided the platform has cpuidle working.

Hope this helps.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

Hi Geert,

On 21/02/17 16:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>> 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.
>>
>> OK, but I don't see any issue with that. That's exactly how it works on
> 
> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
> 

>From wakeup source configuration/management perspective, s2ram and
s2idle are exactly same.

>> ARM Juno platform. The SoC is powered down.
> 
> Good to hear this is not limited to Renesas platforms, so there's a common
> problem to solve.
> 

No, there's no problem to solve. Firmware should enter deepest sleep
state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

>>> 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
>>
>> NACK, you don't need any such properties.
> 
> If this is true for all PSCI platforms, there's indeed no need for such a
> property, and drivers/firmware/psci.c should default to this case.
> 

Cool.

>>> 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:
>>
>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>> what you are doing in this patch set. You also get low latency for free
>> as it just enters the deepest idle state on all CPUs instead of
>> hotplugging out all the secondaries.
> 
> Yes, cfr. "s2idle" above.
> The user can specify to use "s2idle" manually:
> 
>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
> 

This looks like custom file for me.
IIUC, the standard sysfs file for the system PM state is:
	/sys/power/state
1. s2ram:
	$ echo mem > /sys/power/state
2. s2idle
	$ echo freeze > /sys/power/state

> However, how to handle this automatically, e.g. by a distro?

As above

> On most other platforms, userspace can just do e.g.
> 
>     ethtool -s eth0 wol g
> 

That should work.

> to enable wake-on-LAN, and suspend to the deepest supported state using:
> 
>     echo mem > /sys/power/state
> 

This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
can't wakeup if it's powered down, then it should not use that state
to implement SYSTEM_SUSPEND in PSCI firmware or just return the
SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
next available state to enter.

Just botching whatever shallow state you can enter on a particular SoC
into standard "mem" state sounds *horrible* to me.

> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
> make sure to configure to use "s2idle" (or "shallow) instead, else the
> configured wake-up sources won't work.

That's perfect. I was worried that user-space is not doing that. So to
summarize, PSCI firmware either:
1. enters a sane and resumable state in SYSTEM_SUSPEND api
or
2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
   in Linux to enter the deepest idle state.

You literally need no extra work to enter this "freeze" state if the
CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
in this "s2idle" you are referring so far.
Just start with:

	$ cat /sys/power/state

and you should see "freeze" there, if not that's the first thing to
check provided the platform has cpuidle working.

Hope this helps.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

Hi Geert,

On 21/02/17 16:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>> 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.
>>
>> OK, but I don't see any issue with that. That's exactly how it works on
> 
> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
> 

>From wakeup source configuration/management perspective, s2ram and
s2idle are exactly same.

>> ARM Juno platform. The SoC is powered down.
> 
> Good to hear this is not limited to Renesas platforms, so there's a common
> problem to solve.
> 

No, there's no problem to solve. Firmware should enter deepest sleep
state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

>>> 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
>>
>> NACK, you don't need any such properties.
> 
> If this is true for all PSCI platforms, there's indeed no need for such a
> property, and drivers/firmware/psci.c should default to this case.
> 

Cool.

>>> 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:
>>
>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>> what you are doing in this patch set. You also get low latency for free
>> as it just enters the deepest idle state on all CPUs instead of
>> hotplugging out all the secondaries.
> 
> Yes, cfr. "s2idle" above.
> The user can specify to use "s2idle" manually:
> 
>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
> 

This looks like custom file for me.
IIUC, the standard sysfs file for the system PM state is:
	/sys/power/state
1. s2ram:
	$ echo mem > /sys/power/state
2. s2idle
	$ echo freeze > /sys/power/state

> However, how to handle this automatically, e.g. by a distro?

As above

> On most other platforms, userspace can just do e.g.
> 
>     ethtool -s eth0 wol g
> 

That should work.

> to enable wake-on-LAN, and suspend to the deepest supported state using:
> 
>     echo mem > /sys/power/state
> 

This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
can't wakeup if it's powered down, then it should not use that state
to implement SYSTEM_SUSPEND in PSCI firmware or just return the
SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
next available state to enter.

Just botching whatever shallow state you can enter on a particular SoC
into standard "mem" state sounds *horrible* to me.

> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
> make sure to configure to use "s2idle" (or "shallow) instead, else the
> configured wake-up sources won't work.

That's perfect. I was worried that user-space is not doing that. So to
summarize, PSCI firmware either:
1. enters a sane and resumable state in SYSTEM_SUSPEND api
or
2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
   in Linux to enter the deepest idle state.

You literally need no extra work to enter this "freeze" state if the
CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
in this "s2idle" you are referring so far.
Just start with:

	$ cat /sys/power/state

and you should see "freeze" there, if not that's the first thing to
check provided the platform has cpuidle working.

Hope this helps.

-- 
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/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 5:45 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 21/02/17 16:21, Geert Uytterhoeven wrote:
>> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>>> 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.
>>>
>>> OK, but I don't see any issue with that. That's exactly how it works on
>>
>> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
>
> From wakeup source configuration/management perspective, s2ram and
> s2idle are exactly same.

>From the point of view of Linux, that's indeed the case. Linux knows about e.g.
interrupt controllers to keep awake if they're needed for one of the configured
wake-up sources.

PSCI does not know about the wake-up sources configured under Linux.

>>> ARM Juno platform. The SoC is powered down.
>>
>> Good to hear this is not limited to Renesas platforms, so there's a common
>> problem to solve.
>
> No, there's no problem to solve. Firmware should enter deepest sleep
> state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

While SYSTEM_SUSPEND can wake up (e.g. from PMIC), it may not support all
wake-up sources configured from Linux. There's no API to communicate that
information (from Linux to PSCI), or to communicate that limitation (from
PSCI to Linux).

>>>> 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
>>>
>>> NACK, you don't need any such properties.
>>
>> If this is true for all PSCI platforms, there's indeed no need for such a
>> property, and drivers/firmware/psci.c should default to this case.
>
> Cool.
>
>>>> 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:
>>>
>>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>>> what you are doing in this patch set. You also get low latency for free
>>> as it just enters the deepest idle state on all CPUs instead of
>>> hotplugging out all the secondaries.
>>
>> Yes, cfr. "s2idle" above.
>> The user can specify to use "s2idle" manually:
>>
>>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
>
> This looks like custom file for me.

/sys/power/mem_sleep was added in v4.10-rc1, to choose which state to use
for s2ram, cfr. Documentation/power/states.txt.

> IIUC, the standard sysfs file for the system PM state is:
>         /sys/power/state
> 1. s2ram:
>         $ echo mem > /sys/power/state

As of v4.10-rc1, this will use either "s2idle", "shallow", or "deep" mode,
depending on availability and configuration through mem_sleep.
("deep" maps to PSCI SYSTEM_SUSPEND).

> 2. s2idle
>         $ echo freeze > /sys/power/state

Correct.

>> However, how to handle this automatically, e.g. by a distro?
>
> As above

I meant the "mem" one, which should not pick "deep" mode if it cannot wake-up
from that state using the configured wake-up sources.

>> On most other platforms, userspace can just do e.g.
>>
>>     ethtool -s eth0 wol g
>
> That should work.
>
>> to enable wake-on-LAN, and suspend to the deepest supported state using:
>>
>>     echo mem > /sys/power/state
>
> This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
> can't wakeup if it's powered down, then it should not use that state
> to implement SYSTEM_SUSPEND in PSCI firmware or just return the
> SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
> next available state to enter.

The SoC can wake-up. It's just not guaranteed that it can wake-up using
the wakeup-source configured from Linux. Which wakeup-sources are available
depends on the actual PSCI implementation.  It's not specified by the PSCI
specification.

> Just botching whatever shallow state you can enter on a particular SoC
> into standard "mem" state sounds *horrible* to me.

That's more or less what /sys/power/mem_sleep does, though.

>> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
>> make sure to configure to use "s2idle" (or "shallow) instead, else the
>> configured wake-up sources won't work.
>
> That's perfect. I was worried that user-space is not doing that. So to
> summarize, PSCI firmware either:
> 1. enters a sane and resumable state in SYSTEM_SUSPEND api

In this case, it may resume using the PMIC only.
And there's no way for userspace (or even the kernel) to find out!
Hence my solution to:
  - add a DT property to indicate that PSCI will power down the SoC,
  - use "shallow" suspend if any Linux wakeup-sources have been configured
    and the property above is present.

> or
> 2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
>    in Linux to enter the deepest idle state.

In that case, it indeeds falls back to cpuidle/s2idle, which works fine.

> You literally need no extra work to enter this "freeze" state if the
> CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
> in this "s2idle" you are referring so far.
> Just start with:
>
>         $ cat /sys/power/state
>
> and you should see "freeze" there, if not that's the first thing to
> check provided the platform has cpuidle working.

"freeze" is always available.
"deep" is available if PSCI supports SYSTEM_SUSPEND.
My third patch adds "shallow", but it can be dropped (patch 4 can fall
through to cpu_do_idle() when needed, regardless of the existence of shallow).

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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 5:45 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 21/02/17 16:21, Geert Uytterhoeven wrote:
>> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>>> 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.
>>>
>>> OK, but I don't see any issue with that. That's exactly how it works on
>>
>> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
>
> From wakeup source configuration/management perspective, s2ram and
> s2idle are exactly same.

>From the point of view of Linux, that's indeed the case. Linux knows about e.g.
interrupt controllers to keep awake if they're needed for one of the configured
wake-up sources.

PSCI does not know about the wake-up sources configured under Linux.

>>> ARM Juno platform. The SoC is powered down.
>>
>> Good to hear this is not limited to Renesas platforms, so there's a common
>> problem to solve.
>
> No, there's no problem to solve. Firmware should enter deepest sleep
> state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

While SYSTEM_SUSPEND can wake up (e.g. from PMIC), it may not support all
wake-up sources configured from Linux. There's no API to communicate that
information (from Linux to PSCI), or to communicate that limitation (from
PSCI to Linux).

>>>> 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
>>>
>>> NACK, you don't need any such properties.
>>
>> If this is true for all PSCI platforms, there's indeed no need for such a
>> property, and drivers/firmware/psci.c should default to this case.
>
> Cool.
>
>>>> 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:
>>>
>>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>>> what you are doing in this patch set. You also get low latency for free
>>> as it just enters the deepest idle state on all CPUs instead of
>>> hotplugging out all the secondaries.
>>
>> Yes, cfr. "s2idle" above.
>> The user can specify to use "s2idle" manually:
>>
>>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
>
> This looks like custom file for me.

/sys/power/mem_sleep was added in v4.10-rc1, to choose which state to use
for s2ram, cfr. Documentation/power/states.txt.

> IIUC, the standard sysfs file for the system PM state is:
>         /sys/power/state
> 1. s2ram:
>         $ echo mem > /sys/power/state

As of v4.10-rc1, this will use either "s2idle", "shallow", or "deep" mode,
depending on availability and configuration through mem_sleep.
("deep" maps to PSCI SYSTEM_SUSPEND).

> 2. s2idle
>         $ echo freeze > /sys/power/state

Correct.

>> However, how to handle this automatically, e.g. by a distro?
>
> As above

I meant the "mem" one, which should not pick "deep" mode if it cannot wake-up
from that state using the configured wake-up sources.

>> On most other platforms, userspace can just do e.g.
>>
>>     ethtool -s eth0 wol g
>
> That should work.
>
>> to enable wake-on-LAN, and suspend to the deepest supported state using:
>>
>>     echo mem > /sys/power/state
>
> This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
> can't wakeup if it's powered down, then it should not use that state
> to implement SYSTEM_SUSPEND in PSCI firmware or just return the
> SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
> next available state to enter.

The SoC can wake-up. It's just not guaranteed that it can wake-up using
the wakeup-source configured from Linux. Which wakeup-sources are available
depends on the actual PSCI implementation.  It's not specified by the PSCI
specification.

> Just botching whatever shallow state you can enter on a particular SoC
> into standard "mem" state sounds *horrible* to me.

That's more or less what /sys/power/mem_sleep does, though.

>> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
>> make sure to configure to use "s2idle" (or "shallow) instead, else the
>> configured wake-up sources won't work.
>
> That's perfect. I was worried that user-space is not doing that. So to
> summarize, PSCI firmware either:
> 1. enters a sane and resumable state in SYSTEM_SUSPEND api

In this case, it may resume using the PMIC only.
And there's no way for userspace (or even the kernel) to find out!
Hence my solution to:
  - add a DT property to indicate that PSCI will power down the SoC,
  - use "shallow" suspend if any Linux wakeup-sources have been configured
    and the property above is present.

> or
> 2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
>    in Linux to enter the deepest idle state.

In that case, it indeeds falls back to cpuidle/s2idle, which works fine.

> You literally need no extra work to enter this "freeze" state if the
> CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
> in this "s2idle" you are referring so far.
> Just start with:
>
>         $ cat /sys/power/state
>
> and you should see "freeze" there, if not that's the first thing to
> check provided the platform has cpuidle working.

"freeze" is always available.
"deep" is available if PSCI supports SYSTEM_SUSPEND.
My third patch adds "shallow", but it can be dropped (patch 4 can fall
through to cpu_do_idle() when needed, regardless of the existence of shallow).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Tue, Feb 21, 2017 at 5:45 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 21/02/17 16:21, Geert Uytterhoeven wrote:
>> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>>> 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.
>>>
>>> OK, but I don't see any issue with that. That's exactly how it works on
>>
>> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
>
> From wakeup source configuration/management perspective, s2ram and
> s2idle are exactly same.

>From the point of view of Linux, that's indeed the case. Linux knows about e.g.
interrupt controllers to keep awake if they're needed for one of the configured
wake-up sources.

PSCI does not know about the wake-up sources configured under Linux.

>>> ARM Juno platform. The SoC is powered down.
>>
>> Good to hear this is not limited to Renesas platforms, so there's a common
>> problem to solve.
>
> No, there's no problem to solve. Firmware should enter deepest sleep
> state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

While SYSTEM_SUSPEND can wake up (e.g. from PMIC), it may not support all
wake-up sources configured from Linux. There's no API to communicate that
information (from Linux to PSCI), or to communicate that limitation (from
PSCI to Linux).

>>>> 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
>>>
>>> NACK, you don't need any such properties.
>>
>> If this is true for all PSCI platforms, there's indeed no need for such a
>> property, and drivers/firmware/psci.c should default to this case.
>
> Cool.
>
>>>> 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:
>>>
>>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>>> what you are doing in this patch set. You also get low latency for free
>>> as it just enters the deepest idle state on all CPUs instead of
>>> hotplugging out all the secondaries.
>>
>> Yes, cfr. "s2idle" above.
>> The user can specify to use "s2idle" manually:
>>
>>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
>
> This looks like custom file for me.

/sys/power/mem_sleep was added in v4.10-rc1, to choose which state to use
for s2ram, cfr. Documentation/power/states.txt.

> IIUC, the standard sysfs file for the system PM state is:
>         /sys/power/state
> 1. s2ram:
>         $ echo mem > /sys/power/state

As of v4.10-rc1, this will use either "s2idle", "shallow", or "deep" mode,
depending on availability and configuration through mem_sleep.
("deep" maps to PSCI SYSTEM_SUSPEND).

> 2. s2idle
>         $ echo freeze > /sys/power/state

Correct.

>> However, how to handle this automatically, e.g. by a distro?
>
> As above

I meant the "mem" one, which should not pick "deep" mode if it cannot wake-up
from that state using the configured wake-up sources.

>> On most other platforms, userspace can just do e.g.
>>
>>     ethtool -s eth0 wol g
>
> That should work.
>
>> to enable wake-on-LAN, and suspend to the deepest supported state using:
>>
>>     echo mem > /sys/power/state
>
> This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
> can't wakeup if it's powered down, then it should not use that state
> to implement SYSTEM_SUSPEND in PSCI firmware or just return the
> SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
> next available state to enter.

The SoC can wake-up. It's just not guaranteed that it can wake-up using
the wakeup-source configured from Linux. Which wakeup-sources are available
depends on the actual PSCI implementation.  It's not specified by the PSCI
specification.

> Just botching whatever shallow state you can enter on a particular SoC
> into standard "mem" state sounds *horrible* to me.

That's more or less what /sys/power/mem_sleep does, though.

>> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
>> make sure to configure to use "s2idle" (or "shallow) instead, else the
>> configured wake-up sources won't work.
>
> That's perfect. I was worried that user-space is not doing that. So to
> summarize, PSCI firmware either:
> 1. enters a sane and resumable state in SYSTEM_SUSPEND api

In this case, it may resume using the PMIC only.
And there's no way for userspace (or even the kernel) to find out!
Hence my solution to:
  - add a DT property to indicate that PSCI will power down the SoC,
  - use "shallow" suspend if any Linux wakeup-sources have been configured
    and the property above is present.

> or
> 2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
>    in Linux to enter the deepest idle state.

In that case, it indeeds falls back to cpuidle/s2idle, which works fine.

> You literally need no extra work to enter this "freeze" state if the
> CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
> in this "s2idle" you are referring so far.
> Just start with:
>
>         $ cat /sys/power/state
>
> and you should see "freeze" there, if not that's the first thing to
> check provided the platform has cpuidle working.

"freeze" is always available.
"deep" is available if PSCI supports SYSTEM_SUSPEND.
My third patch adds "shallow", but it can be dropped (patch 4 can fall
through to cpu_do_idle() when needed, regardless of the existence of shallow).

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

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

[Sudeep Holla]

On 21/02/17 17:34, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 5:45 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 21/02/17 16:21, Geert Uytterhoeven wrote:
>>> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>>>> 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.
>>>>
>>>> OK, but I don't see any issue with that. That's exactly how it works on
>>>
>>> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
>>
>> From wakeup source configuration/management perspective, s2ram and
>> s2idle are exactly same.
> 
> From the point of view of Linux, that's indeed the case. Linux knows about e.g.
> interrupt controllers to keep awake if they're needed for one of the configured
> wake-up sources.
> 

Correct.

> PSCI does not know about the wake-up sources configured under Linux.
>

And the PSCI for a particular platform has to respect those
configurations if they powered down the interrupt controller. They need
to read those wakeups and configure the wakeup controller if required.

Also note we can't mark any device as wakeup source in the device tree
in there's dedicated wakeup controller to enable them and main interrupt
controller is powered down.

>>>> ARM Juno platform. The SoC is powered down.
>>>
>>> Good to hear this is not limited to Renesas platforms, so there's a common
>>> problem to solve.
>>
>> No, there's no problem to solve. Firmware should enter deepest sleep
>> state in the system with SYSTEM_SUSPEND from which it can wakeup of course.
> 
> While SYSTEM_SUSPEND can wake up (e.g. from PMIC), it may not support all
> wake-up sources configured from Linux. There's no API to communicate that
> information (from Linux to PSCI), or to communicate that limitation (from
> PSCI to Linux).
> 

It's platform specific. The SYSTEM_SUSPEND implementation will be aware
of the platform and it's wakeup configuration. As mention above, it
needs to take some action if required.

[...]

>>>>> 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:
>>>>
>>>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>>>> what you are doing in this patch set. You also get low latency for free
>>>> as it just enters the deepest idle state on all CPUs instead of
>>>> hotplugging out all the secondaries.
>>>
>>> Yes, cfr. "s2idle" above.
>>> The user can specify to use "s2idle" manually:
>>>
>>>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
>>
>> This looks like custom file for me.
> 
> /sys/power/mem_sleep was added in v4.10-rc1, to choose which state to use
> for s2ram, cfr. Documentation/power/states.txt.
>

OK, that's new to me. I need to read and understand that then. Sorry for
the noise. I was unaware of that.

>> IIUC, the standard sysfs file for the system PM state is:
>>         /sys/power/state
>> 1. s2ram:
>>         $ echo mem > /sys/power/state
> 
> As of v4.10-rc1, this will use either "s2idle", "shallow", or "deep" mode,
> depending on availability and configuration through mem_sleep.
> ("deep" maps to PSCI SYSTEM_SUSPEND).
> 
>> 2. s2idle
>>         $ echo freeze > /sys/power/state
> 
> Correct.
> 
>>> However, how to handle this automatically, e.g. by a distro?
>>
>> As above
> 
> I meant the "mem" one, which should not pick "deep" mode if it cannot wake-up
> from that state using the configured wake-up sources.
> 
>>> On most other platforms, userspace can just do e.g.
>>>
>>>     ethtool -s eth0 wol g
>>
>> That should work.
>>
>>> to enable wake-on-LAN, and suspend to the deepest supported state using:
>>>
>>>     echo mem > /sys/power/state
>>
>> This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
>> can't wakeup if it's powered down, then it should not use that state
>> to implement SYSTEM_SUSPEND in PSCI firmware or just return the
>> SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
>> next available state to enter.
> 
> The SoC can wake-up. It's just not guaranteed that it can wake-up using
> the wakeup-source configured from Linux. Which wakeup-sources are available
> depends on the actual PSCI implementation.  It's not specified by the PSCI
> specification.
> 
>> Just botching whatever shallow state you can enter on a particular SoC
>> into standard "mem" state sounds *horrible* to me.
> 
> That's more or less what /sys/power/mem_sleep does, though.
> 

OK, I will go through that in detail.

>>> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
>>> make sure to configure to use "s2idle" (or "shallow) instead, else the
>>> configured wake-up sources won't work.
>>
>> That's perfect. I was worried that user-space is not doing that. So to
>> summarize, PSCI firmware either:
>> 1. enters a sane and resumable state in SYSTEM_SUSPEND api
> 
> In this case, it may resume using the PMIC only.
> And there's no way for userspace (or even the kernel) to find out!
> Hence my solution to:
>   - add a DT property to indicate that PSCI will power down the SoC,
>   - use "shallow" suspend if any Linux wakeup-sources have been configured
>     and the property above is present.
> 

But what you are doing is *exactly* same as "freeze" state except the
secondaries powered off instead of idling. So my NACK is mainly for that
reason. Had you done something different, then yes, it should be considered.

>> or
>> 2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
>>    in Linux to enter the deepest idle state.
> 
> In that case, it indeeds falls back to cpuidle/s2idle, which works fine.
> 
>> You literally need no extra work to enter this "freeze" state if the
>> CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
>> in this "s2idle" you are referring so far.
>> Just start with:
>>
>>         $ cat /sys/power/state
>>
>> and you should see "freeze" there, if not that's the first thing to
>> check provided the platform has cpuidle working.
> 
> "freeze" is always available.
> "deep" is available if PSCI supports SYSTEM_SUSPEND.
> My third patch adds "shallow", but it can be dropped (patch 4 can fall
> through to cpu_do_idle() when needed, regardless of the existence of shallow).
> 

I understand that. But tell me how is that any different from the
"freeze" state. Why do you need that new state at all. Again just
because there's a new feature added doesn't mean we need to use it for
sake of using it. If "freeze" != "shallow", then we can explore this
further. But it's not in your case and hence I see no real need for this.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 17:34, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 5:45 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 21/02/17 16:21, Geert Uytterhoeven wrote:
>>> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>>>> 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.
>>>>
>>>> OK, but I don't see any issue with that. That's exactly how it works on
>>>
>>> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
>>
>> From wakeup source configuration/management perspective, s2ram and
>> s2idle are exactly same.
> 
> From the point of view of Linux, that's indeed the case. Linux knows about e.g.
> interrupt controllers to keep awake if they're needed for one of the configured
> wake-up sources.
> 

Correct.

> PSCI does not know about the wake-up sources configured under Linux.
>

And the PSCI for a particular platform has to respect those
configurations if they powered down the interrupt controller. They need
to read those wakeups and configure the wakeup controller if required.

Also note we can't mark any device as wakeup source in the device tree
in there's dedicated wakeup controller to enable them and main interrupt
controller is powered down.

>>>> ARM Juno platform. The SoC is powered down.
>>>
>>> Good to hear this is not limited to Renesas platforms, so there's a common
>>> problem to solve.
>>
>> No, there's no problem to solve. Firmware should enter deepest sleep
>> state in the system with SYSTEM_SUSPEND from which it can wakeup of course.
> 
> While SYSTEM_SUSPEND can wake up (e.g. from PMIC), it may not support all
> wake-up sources configured from Linux. There's no API to communicate that
> information (from Linux to PSCI), or to communicate that limitation (from
> PSCI to Linux).
> 

It's platform specific. The SYSTEM_SUSPEND implementation will be aware
of the platform and it's wakeup configuration. As mention above, it
needs to take some action if required.

[...]

>>>>> 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:
>>>>
>>>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>>>> what you are doing in this patch set. You also get low latency for free
>>>> as it just enters the deepest idle state on all CPUs instead of
>>>> hotplugging out all the secondaries.
>>>
>>> Yes, cfr. "s2idle" above.
>>> The user can specify to use "s2idle" manually:
>>>
>>>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
>>
>> This looks like custom file for me.
> 
> /sys/power/mem_sleep was added in v4.10-rc1, to choose which state to use
> for s2ram, cfr. Documentation/power/states.txt.
>

OK, that's new to me. I need to read and understand that then. Sorry for
the noise. I was unaware of that.

>> IIUC, the standard sysfs file for the system PM state is:
>>         /sys/power/state
>> 1. s2ram:
>>         $ echo mem > /sys/power/state
> 
> As of v4.10-rc1, this will use either "s2idle", "shallow", or "deep" mode,
> depending on availability and configuration through mem_sleep.
> ("deep" maps to PSCI SYSTEM_SUSPEND).
> 
>> 2. s2idle
>>         $ echo freeze > /sys/power/state
> 
> Correct.
> 
>>> However, how to handle this automatically, e.g. by a distro?
>>
>> As above
> 
> I meant the "mem" one, which should not pick "deep" mode if it cannot wake-up
> from that state using the configured wake-up sources.
> 
>>> On most other platforms, userspace can just do e.g.
>>>
>>>     ethtool -s eth0 wol g
>>
>> That should work.
>>
>>> to enable wake-on-LAN, and suspend to the deepest supported state using:
>>>
>>>     echo mem > /sys/power/state
>>
>> This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
>> can't wakeup if it's powered down, then it should not use that state
>> to implement SYSTEM_SUSPEND in PSCI firmware or just return the
>> SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
>> next available state to enter.
> 
> The SoC can wake-up. It's just not guaranteed that it can wake-up using
> the wakeup-source configured from Linux. Which wakeup-sources are available
> depends on the actual PSCI implementation.  It's not specified by the PSCI
> specification.
> 
>> Just botching whatever shallow state you can enter on a particular SoC
>> into standard "mem" state sounds *horrible* to me.
> 
> That's more or less what /sys/power/mem_sleep does, though.
> 

OK, I will go through that in detail.

>>> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
>>> make sure to configure to use "s2idle" (or "shallow) instead, else the
>>> configured wake-up sources won't work.
>>
>> That's perfect. I was worried that user-space is not doing that. So to
>> summarize, PSCI firmware either:
>> 1. enters a sane and resumable state in SYSTEM_SUSPEND api
> 
> In this case, it may resume using the PMIC only.
> And there's no way for userspace (or even the kernel) to find out!
> Hence my solution to:
>   - add a DT property to indicate that PSCI will power down the SoC,
>   - use "shallow" suspend if any Linux wakeup-sources have been configured
>     and the property above is present.
> 

But what you are doing is *exactly* same as "freeze" state except the
secondaries powered off instead of idling. So my NACK is mainly for that
reason. Had you done something different, then yes, it should be considered.

>> or
>> 2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
>>    in Linux to enter the deepest idle state.
> 
> In that case, it indeeds falls back to cpuidle/s2idle, which works fine.
> 
>> You literally need no extra work to enter this "freeze" state if the
>> CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
>> in this "s2idle" you are referring so far.
>> Just start with:
>>
>>         $ cat /sys/power/state
>>
>> and you should see "freeze" there, if not that's the first thing to
>> check provided the platform has cpuidle working.
> 
> "freeze" is always available.
> "deep" is available if PSCI supports SYSTEM_SUSPEND.
> My third patch adds "shallow", but it can be dropped (patch 4 can fall
> through to cpu_do_idle() when needed, regardless of the existence of shallow).
> 

I understand that. But tell me how is that any different from the
"freeze" state. Why do you need that new state at all. Again just
because there's a new feature added doesn't mean we need to use it for
sake of using it. If "freeze" != "shallow", then we can explore this
further. But it's not in your case and hence I see no real need for this.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 17:34, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 5:45 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 21/02/17 16:21, Geert Uytterhoeven wrote:
>>> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>>>> 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.
>>>>
>>>> OK, but I don't see any issue with that. That's exactly how it works on
>>>
>>> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
>>
>> From wakeup source configuration/management perspective, s2ram and
>> s2idle are exactly same.
> 
> From the point of view of Linux, that's indeed the case. Linux knows about e.g.
> interrupt controllers to keep awake if they're needed for one of the configured
> wake-up sources.
> 

Correct.

> PSCI does not know about the wake-up sources configured under Linux.
>

And the PSCI for a particular platform has to respect those
configurations if they powered down the interrupt controller. They need
to read those wakeups and configure the wakeup controller if required.

Also note we can't mark any device as wakeup source in the device tree
in there's dedicated wakeup controller to enable them and main interrupt
controller is powered down.

>>>> ARM Juno platform. The SoC is powered down.
>>>
>>> Good to hear this is not limited to Renesas platforms, so there's a common
>>> problem to solve.
>>
>> No, there's no problem to solve. Firmware should enter deepest sleep
>> state in the system with SYSTEM_SUSPEND from which it can wakeup of course.
> 
> While SYSTEM_SUSPEND can wake up (e.g. from PMIC), it may not support all
> wake-up sources configured from Linux. There's no API to communicate that
> information (from Linux to PSCI), or to communicate that limitation (from
> PSCI to Linux).
> 

It's platform specific. The SYSTEM_SUSPEND implementation will be aware
of the platform and it's wakeup configuration. As mention above, it
needs to take some action if required.

[...]

>>>>> 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:
>>>>
>>>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>>>> what you are doing in this patch set. You also get low latency for free
>>>> as it just enters the deepest idle state on all CPUs instead of
>>>> hotplugging out all the secondaries.
>>>
>>> Yes, cfr. "s2idle" above.
>>> The user can specify to use "s2idle" manually:
>>>
>>>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
>>
>> This looks like custom file for me.
> 
> /sys/power/mem_sleep was added in v4.10-rc1, to choose which state to use
> for s2ram, cfr. Documentation/power/states.txt.
>

OK, that's new to me. I need to read and understand that then. Sorry for
the noise. I was unaware of that.

>> IIUC, the standard sysfs file for the system PM state is:
>>         /sys/power/state
>> 1. s2ram:
>>         $ echo mem > /sys/power/state
> 
> As of v4.10-rc1, this will use either "s2idle", "shallow", or "deep" mode,
> depending on availability and configuration through mem_sleep.
> ("deep" maps to PSCI SYSTEM_SUSPEND).
> 
>> 2. s2idle
>>         $ echo freeze > /sys/power/state
> 
> Correct.
> 
>>> However, how to handle this automatically, e.g. by a distro?
>>
>> As above
> 
> I meant the "mem" one, which should not pick "deep" mode if it cannot wake-up
> from that state using the configured wake-up sources.
> 
>>> On most other platforms, userspace can just do e.g.
>>>
>>>     ethtool -s eth0 wol g
>>
>> That should work.
>>
>>> to enable wake-on-LAN, and suspend to the deepest supported state using:
>>>
>>>     echo mem > /sys/power/state
>>
>> This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
>> can't wakeup if it's powered down, then it should not use that state
>> to implement SYSTEM_SUSPEND in PSCI firmware or just return the
>> SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
>> next available state to enter.
> 
> The SoC can wake-up. It's just not guaranteed that it can wake-up using
> the wakeup-source configured from Linux. Which wakeup-sources are available
> depends on the actual PSCI implementation.  It's not specified by the PSCI
> specification.
> 
>> Just botching whatever shallow state you can enter on a particular SoC
>> into standard "mem" state sounds *horrible* to me.
> 
> That's more or less what /sys/power/mem_sleep does, though.
> 

OK, I will go through that in detail.

>>> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
>>> make sure to configure to use "s2idle" (or "shallow) instead, else the
>>> configured wake-up sources won't work.
>>
>> That's perfect. I was worried that user-space is not doing that. So to
>> summarize, PSCI firmware either:
>> 1. enters a sane and resumable state in SYSTEM_SUSPEND api
> 
> In this case, it may resume using the PMIC only.
> And there's no way for userspace (or even the kernel) to find out!
> Hence my solution to:
>   - add a DT property to indicate that PSCI will power down the SoC,
>   - use "shallow" suspend if any Linux wakeup-sources have been configured
>     and the property above is present.
> 

But what you are doing is *exactly* same as "freeze" state except the
secondaries powered off instead of idling. So my NACK is mainly for that
reason. Had you done something different, then yes, it should be considered.

>> or
>> 2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
>>    in Linux to enter the deepest idle state.
> 
> In that case, it indeeds falls back to cpuidle/s2idle, which works fine.
> 
>> You literally need no extra work to enter this "freeze" state if the
>> CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
>> in this "s2idle" you are referring so far.
>> Just start with:
>>
>>         $ cat /sys/power/state
>>
>> and you should see "freeze" there, if not that's the first thing to
>> check provided the platform has cpuidle working.
> 
> "freeze" is always available.
> "deep" is available if PSCI supports SYSTEM_SUSPEND.
> My third patch adds "shallow", but it can be dropped (patch 4 can fall
> through to cpu_do_idle() when needed, regardless of the existence of shallow).
> 

I understand that. But tell me how is that any different from the
"freeze" state. Why do you need that new state at all. Again just
because there's a new feature added doesn't mean we need to use it for
sake of using it. If "freeze" != "shallow", then we can explore this
further. But it's not in your case and hence I see no real need for this.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 17:51, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:34, Geert Uytterhoeven wrote:

[...]

>>
>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>> the wakeup-source configured from Linux. Which wakeup-sources are available
>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>> specification.
>>
>>> Just botching whatever shallow state you can enter on a particular SoC
>>> into standard "mem" state sounds *horrible* to me.
>>
>> That's more or less what /sys/power/mem_sleep does, though.
>>
> 
> OK, I will go through that in detail.
> 

OK, I went through the patch and the main intention is was added.
So I will begin by summarizing my understanding:

A new suspend interface(/sys/power/mem_sleep) is added to allow the
"mem" string in /sys/power/state to represent multiple things that can
be selected.

Before:
A. echo freeze > /sys/power/state ---> Enters s2idle
B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)

After:
1. echo freeze > /sys/power/state ---> Enters s2idle still same
2. echo s2idle > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2idle
3. echo deep > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)

Please note I have carefully dropped standby/shallow as we will not
support that state on ARM64 platforms(refer previous discussions for the
same)

Now IIUC, you need 2 above. So, since this new interface allow mem to
mean "s2idle", we need to fix the core to register default suspend_ops
to achieve what you need. And since I now better understand you problem,
you get extra NACK for this series ;)

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 17:51, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:34, Geert Uytterhoeven wrote:

[...]

>>
>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>> the wakeup-source configured from Linux. Which wakeup-sources are available
>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>> specification.
>>
>>> Just botching whatever shallow state you can enter on a particular SoC
>>> into standard "mem" state sounds *horrible* to me.
>>
>> That's more or less what /sys/power/mem_sleep does, though.
>>
> 
> OK, I will go through that in detail.
> 

OK, I went through the patch and the main intention is was added.
So I will begin by summarizing my understanding:

A new suspend interface(/sys/power/mem_sleep) is added to allow the
"mem" string in /sys/power/state to represent multiple things that can
be selected.

Before:
A. echo freeze > /sys/power/state ---> Enters s2idle
B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)

After:
1. echo freeze > /sys/power/state ---> Enters s2idle still same
2. echo s2idle > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2idle
3. echo deep > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)

Please note I have carefully dropped standby/shallow as we will not
support that state on ARM64 platforms(refer previous discussions for the
same)

Now IIUC, you need 2 above. So, since this new interface allow mem to
mean "s2idle", we need to fix the core to register default suspend_ops
to achieve what you need. And since I now better understand you problem,
you get extra NACK for this series ;)

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 17:51, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:34, Geert Uytterhoeven wrote:

[...]

>>
>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>> the wakeup-source configured from Linux. Which wakeup-sources are available
>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>> specification.
>>
>>> Just botching whatever shallow state you can enter on a particular SoC
>>> into standard "mem" state sounds *horrible* to me.
>>
>> That's more or less what /sys/power/mem_sleep does, though.
>>
> 
> OK, I will go through that in detail.
> 

OK, I went through the patch and the main intention is was added.
So I will begin by summarizing my understanding:

A new suspend interface(/sys/power/mem_sleep) is added to allow the
"mem" string in /sys/power/state to represent multiple things that can
be selected.

Before:
A. echo freeze > /sys/power/state ---> Enters s2idle
B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)

After:
1. echo freeze > /sys/power/state ---> Enters s2idle still same
2. echo s2idle > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2idle
3. echo deep > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)

Please note I have carefully dropped standby/shallow as we will not
support that state on ARM64 platforms(refer previous discussions for the
same)

Now IIUC, you need 2 above. So, since this new interface allow mem to
mean "s2idle", we need to fix the core to register default suspend_ops
to achieve what you need. And since I now better understand you problem,
you get extra NACK for this series ;)

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 17:51, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:34, Geert Uytterhoeven wrote:

[...]

>>
>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>> the wakeup-source configured from Linux. Which wakeup-sources are available
>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>> specification.
>>
>>> Just botching whatever shallow state you can enter on a particular SoC
>>> into standard "mem" state sounds *horrible* to me.
>>
>> That's more or less what /sys/power/mem_sleep does, though.
>>
> 
> OK, I will go through that in detail.
> 

OK, I went through the patch and the main intention is was added.
So I will begin by summarizing my understanding:

A new suspend interface(/sys/power/mem_sleep) is added to allow the
"mem" string in /sys/power/state to represent multiple things that can
be selected.

Before:
A. echo freeze > /sys/power/state ---> Enters s2idle
B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)

After:
1. echo freeze > /sys/power/state ---> Enters s2idle still same
2. echo s2idle > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2idle
3. echo deep > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)

Please note I have carefully dropped standby/shallow as we will not
support that state on ARM64 platforms(refer previous discussions for the
same)

Now IIUC, you need 2 above. So, since this new interface allow mem to
mean "s2idle", we need to fix the core to register default suspend_ops
to achieve what you need. And since I now better understand you problem,
you get extra NACK for this series ;)

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 18:27, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:51, Sudeep Holla wrote:
>>
>>
>> On 21/02/17 17:34, Geert Uytterhoeven wrote:
> 
> [...]
> 
>>>
>>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>>> the wakeup-source configured from Linux. Which wakeup-sources are available
>>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>>> specification.
>>>
>>>> Just botching whatever shallow state you can enter on a particular SoC
>>>> into standard "mem" state sounds *horrible* to me.
>>>
>>> That's more or less what /sys/power/mem_sleep does, though.
>>>
>>
>> OK, I will go through that in detail.
>>
> 
> OK, I went through the patch and the main intention is was added.
> So I will begin by summarizing my understanding:
> 
> A new suspend interface(/sys/power/mem_sleep) is added to allow the
> "mem" string in /sys/power/state to represent multiple things that can
> be selected.
> 
> Before:
> A. echo freeze > /sys/power/state ---> Enters s2idle
> B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
> 
> After:
> 1. echo freeze > /sys/power/state ---> Enters s2idle still same
> 2. echo s2idle > /sys/power/mem_sleep
>    echo mem > /sys/power/state ---> Also enter s2idle
> 3. echo deep > /sys/power/mem_sleep
>    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
> 
> Please note I have carefully dropped standby/shallow as we will not
> support that state on ARM64 platforms(refer previous discussions for the
> same)
> 
> Now IIUC, you need 2 above. So, since this new interface allow mem to
> mean "s2idle", we need to fix the core to register default suspend_ops
> to achieve what you need. 

I take this back, you have everything you need in place, nothing needs
to be done. I just checked again. If I don't register PSCI suspend_ops,
I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
which is exactly what we need. Again we don't support standby/shallow
state on ARM64/PSCI.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 18:27, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:51, Sudeep Holla wrote:
>>
>>
>> On 21/02/17 17:34, Geert Uytterhoeven wrote:
> 
> [...]
> 
>>>
>>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>>> the wakeup-source configured from Linux. Which wakeup-sources are available
>>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>>> specification.
>>>
>>>> Just botching whatever shallow state you can enter on a particular SoC
>>>> into standard "mem" state sounds *horrible* to me.
>>>
>>> That's more or less what /sys/power/mem_sleep does, though.
>>>
>>
>> OK, I will go through that in detail.
>>
> 
> OK, I went through the patch and the main intention is was added.
> So I will begin by summarizing my understanding:
> 
> A new suspend interface(/sys/power/mem_sleep) is added to allow the
> "mem" string in /sys/power/state to represent multiple things that can
> be selected.
> 
> Before:
> A. echo freeze > /sys/power/state ---> Enters s2idle
> B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
> 
> After:
> 1. echo freeze > /sys/power/state ---> Enters s2idle still same
> 2. echo s2idle > /sys/power/mem_sleep
>    echo mem > /sys/power/state ---> Also enter s2idle
> 3. echo deep > /sys/power/mem_sleep
>    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
> 
> Please note I have carefully dropped standby/shallow as we will not
> support that state on ARM64 platforms(refer previous discussions for the
> same)
> 
> Now IIUC, you need 2 above. So, since this new interface allow mem to
> mean "s2idle", we need to fix the core to register default suspend_ops
> to achieve what you need. 

I take this back, you have everything you need in place, nothing needs
to be done. I just checked again. If I don't register PSCI suspend_ops,
I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
which is exactly what we need. Again we don't support standby/shallow
state on ARM64/PSCI.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 18:27, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:51, Sudeep Holla wrote:
>>
>>
>> On 21/02/17 17:34, Geert Uytterhoeven wrote:
> 
> [...]
> 
>>>
>>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>>> the wakeup-source configured from Linux. Which wakeup-sources are available
>>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>>> specification.
>>>
>>>> Just botching whatever shallow state you can enter on a particular SoC
>>>> into standard "mem" state sounds *horrible* to me.
>>>
>>> That's more or less what /sys/power/mem_sleep does, though.
>>>
>>
>> OK, I will go through that in detail.
>>
> 
> OK, I went through the patch and the main intention is was added.
> So I will begin by summarizing my understanding:
> 
> A new suspend interface(/sys/power/mem_sleep) is added to allow the
> "mem" string in /sys/power/state to represent multiple things that can
> be selected.
> 
> Before:
> A. echo freeze > /sys/power/state ---> Enters s2idle
> B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
> 
> After:
> 1. echo freeze > /sys/power/state ---> Enters s2idle still same
> 2. echo s2idle > /sys/power/mem_sleep
>    echo mem > /sys/power/state ---> Also enter s2idle
> 3. echo deep > /sys/power/mem_sleep
>    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
> 
> Please note I have carefully dropped standby/shallow as we will not
> support that state on ARM64 platforms(refer previous discussions for the
> same)
> 
> Now IIUC, you need 2 above. So, since this new interface allow mem to
> mean "s2idle", we need to fix the core to register default suspend_ops
> to achieve what you need. 

I take this back, you have everything you need in place, nothing needs
to be done. I just checked again. If I don't register PSCI suspend_ops,
I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
which is exactly what we need. Again we don't support standby/shallow
state on ARM64/PSCI.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 21/02/17 18:27, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:51, Sudeep Holla wrote:
>>
>>
>> On 21/02/17 17:34, Geert Uytterhoeven wrote:
> 
> [...]
> 
>>>
>>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>>> the wakeup-source configured from Linux. Which wakeup-sources are available
>>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>>> specification.
>>>
>>>> Just botching whatever shallow state you can enter on a particular SoC
>>>> into standard "mem" state sounds *horrible* to me.
>>>
>>> That's more or less what /sys/power/mem_sleep does, though.
>>>
>>
>> OK, I will go through that in detail.
>>
> 
> OK, I went through the patch and the main intention is was added.
> So I will begin by summarizing my understanding:
> 
> A new suspend interface(/sys/power/mem_sleep) is added to allow the
> "mem" string in /sys/power/state to represent multiple things that can
> be selected.
> 
> Before:
> A. echo freeze > /sys/power/state ---> Enters s2idle
> B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
> 
> After:
> 1. echo freeze > /sys/power/state ---> Enters s2idle still same
> 2. echo s2idle > /sys/power/mem_sleep
>    echo mem > /sys/power/state ---> Also enter s2idle
> 3. echo deep > /sys/power/mem_sleep
>    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
> 
> Please note I have carefully dropped standby/shallow as we will not
> support that state on ARM64 platforms(refer previous discussions for the
> same)
> 
> Now IIUC, you need 2 above. So, since this new interface allow mem to
> mean "s2idle", we need to fix the core to register default suspend_ops
> to achieve what you need. 

I take this back, you have everything you need in place, nothing needs
to be done. I just checked again. If I don't register PSCI suspend_ops,
I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
which is exactly what we need. Again we don't support standby/shallow
state on ARM64/PSCI.

-- 
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/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

[Rafael J. Wysocki]

On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
> 
> On 21/02/17 18:27, Sudeep Holla wrote:
> > 
> > 
> > On 21/02/17 17:51, Sudeep Holla wrote:
> >>
> >>
> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
> > 
> > [...]
> > 
> >>>
> >>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
> >>> the wakeup-source configured from Linux. Which wakeup-sources are available
> >>> depends on the actual PSCI implementation.  It's not specified by the PSCI
> >>> specification.
> >>>
> >>>> Just botching whatever shallow state you can enter on a particular SoC
> >>>> into standard "mem" state sounds *horrible* to me.
> >>>
> >>> That's more or less what /sys/power/mem_sleep does, though.
> >>>
> >>
> >> OK, I will go through that in detail.
> >>
> > 
> > OK, I went through the patch and the main intention is was added.
> > So I will begin by summarizing my understanding:
> > 
> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
> > "mem" string in /sys/power/state to represent multiple things that can
> > be selected.
> > 
> > Before:
> > A. echo freeze > /sys/power/state ---> Enters s2idle
> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
> > 
> > After:
> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
> > 2. echo s2idle > /sys/power/mem_sleep
> >    echo mem > /sys/power/state ---> Also enter s2idle
> > 3. echo deep > /sys/power/mem_sleep
> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
> > 
> > Please note I have carefully dropped standby/shallow as we will not
> > support that state on ARM64 platforms(refer previous discussions for the
> > same)
> > 
> > Now IIUC, you need 2 above. So, since this new interface allow mem to
> > mean "s2idle", we need to fix the core to register default suspend_ops
> > to achieve what you need. 
> 
> I take this back, you have everything you need in place, nothing needs
> to be done. I just checked again. If I don't register PSCI suspend_ops,
> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
> which is exactly what we need. Again we don't support standby/shallow
> state on ARM64/PSCI.

Except for one thing which may or may not be a concern here.

Suspend to idle should only go into states in which all of the available wakeup
devices work.  If there are devices that cannot wake you up from a given state,
this isn't "idle" any more, is it?

As for the device wakeup disable/enable interface, it is for controlling
whether or not a given device should be allowed to generate wakeup signals at
all.

The information on what states a given device can wake up the system from is
platform-specific and generally would need to be taken into consideration at
the platform level.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
> 
> On 21/02/17 18:27, Sudeep Holla wrote:
> > 
> > 
> > On 21/02/17 17:51, Sudeep Holla wrote:
> >>
> >>
> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
> > 
> > [...]
> > 
> >>>
> >>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
> >>> the wakeup-source configured from Linux. Which wakeup-sources are available
> >>> depends on the actual PSCI implementation.  It's not specified by the PSCI
> >>> specification.
> >>>
> >>>> Just botching whatever shallow state you can enter on a particular SoC
> >>>> into standard "mem" state sounds *horrible* to me.
> >>>
> >>> That's more or less what /sys/power/mem_sleep does, though.
> >>>
> >>
> >> OK, I will go through that in detail.
> >>
> > 
> > OK, I went through the patch and the main intention is was added.
> > So I will begin by summarizing my understanding:
> > 
> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
> > "mem" string in /sys/power/state to represent multiple things that can
> > be selected.
> > 
> > Before:
> > A. echo freeze > /sys/power/state ---> Enters s2idle
> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
> > 
> > After:
> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
> > 2. echo s2idle > /sys/power/mem_sleep
> >    echo mem > /sys/power/state ---> Also enter s2idle
> > 3. echo deep > /sys/power/mem_sleep
> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
> > 
> > Please note I have carefully dropped standby/shallow as we will not
> > support that state on ARM64 platforms(refer previous discussions for the
> > same)
> > 
> > Now IIUC, you need 2 above. So, since this new interface allow mem to
> > mean "s2idle", we need to fix the core to register default suspend_ops
> > to achieve what you need. 
> 
> I take this back, you have everything you need in place, nothing needs
> to be done. I just checked again. If I don't register PSCI suspend_ops,
> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
> which is exactly what we need. Again we don't support standby/shallow
> state on ARM64/PSCI.

Except for one thing which may or may not be a concern here.

Suspend to idle should only go into states in which all of the available wakeup
devices work.  If there are devices that cannot wake you up from a given state,
this isn't "idle" any more, is it?

As for the device wakeup disable/enable interface, it is for controlling
whether or not a given device should be allowed to generate wakeup signals at
all.

The information on what states a given device can wake up the system from is
platform-specific and generally would need to be taken into consideration at
the platform level.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
> 
> On 21/02/17 18:27, Sudeep Holla wrote:
> > 
> > 
> > On 21/02/17 17:51, Sudeep Holla wrote:
> >>
> >>
> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
> > 
> > [...]
> > 
> >>>
> >>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
> >>> the wakeup-source configured from Linux. Which wakeup-sources are available
> >>> depends on the actual PSCI implementation.  It's not specified by the PSCI
> >>> specification.
> >>>
> >>>> Just botching whatever shallow state you can enter on a particular SoC
> >>>> into standard "mem" state sounds *horrible* to me.
> >>>
> >>> That's more or less what /sys/power/mem_sleep does, though.
> >>>
> >>
> >> OK, I will go through that in detail.
> >>
> > 
> > OK, I went through the patch and the main intention is was added.
> > So I will begin by summarizing my understanding:
> > 
> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
> > "mem" string in /sys/power/state to represent multiple things that can
> > be selected.
> > 
> > Before:
> > A. echo freeze > /sys/power/state ---> Enters s2idle
> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
> > 
> > After:
> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
> > 2. echo s2idle > /sys/power/mem_sleep
> >    echo mem > /sys/power/state ---> Also enter s2idle
> > 3. echo deep > /sys/power/mem_sleep
> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
> > 
> > Please note I have carefully dropped standby/shallow as we will not
> > support that state on ARM64 platforms(refer previous discussions for the
> > same)
> > 
> > Now IIUC, you need 2 above. So, since this new interface allow mem to
> > mean "s2idle", we need to fix the core to register default suspend_ops
> > to achieve what you need. 
> 
> I take this back, you have everything you need in place, nothing needs
> to be done. I just checked again. If I don't register PSCI suspend_ops,
> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
> which is exactly what we need. Again we don't support standby/shallow
> state on ARM64/PSCI.

Except for one thing which may or may not be a concern here.

Suspend to idle should only go into states in which all of the available wakeup
devices work.  If there are devices that cannot wake you up from a given state,
this isn't "idle" any more, is it?

As for the device wakeup disable/enable interface, it is for controlling
whether or not a given device should be allowed to generate wakeup signals at
all.

The information on what states a given device can wake up the system from is
platform-specific and generally would need to be taken into consideration at
the platform level.

Thanks,
Rafael

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

[Sudeep Holla]

On 22/02/17 01:14, Rafael J. Wysocki wrote:
> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:

[...]

>>
>> I take this back, you have everything you need in place, nothing needs
>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>> which is exactly what we need. Again we don't support standby/shallow
>> state on ARM64/PSCI.
> 
> Except for one thing which may or may not be a concern here.
> 
> Suspend to idle should only go into states in which all of the available wakeup
> devices work.  If there are devices that cannot wake you up from a given state,
> this isn't "idle" any more, is it?
> 

True. In this Renasas platform, since the platform doesn't have PSCI
system suspend, we can only support s2idle and not s2ram. In this case
we don't ask platform to enter some system state whereas we suspend all
the devices(leaving wakeup capable devices active) and ask platform to
enter deepest idle state on all the CPUs. I still don't understand the
issue Geert is facing.

Geert, so far you have failed to explain what's different from the new
state you are adding and the existing s2idle.

> As for the device wakeup disable/enable interface, it is for controlling
> whether or not a given device should be allowed to generate wakeup signals at
> all.
> 
> The information on what states a given device can wake up the system from is
> platform-specific and generally would need to be taken into consideration at
> the platform level.
> 

Exactly, that's what I am trying to convince Geert ;)

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 22/02/17 01:14, Rafael J. Wysocki wrote:
> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:

[...]

>>
>> I take this back, you have everything you need in place, nothing needs
>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>> which is exactly what we need. Again we don't support standby/shallow
>> state on ARM64/PSCI.
> 
> Except for one thing which may or may not be a concern here.
> 
> Suspend to idle should only go into states in which all of the available wakeup
> devices work.  If there are devices that cannot wake you up from a given state,
> this isn't "idle" any more, is it?
> 

True. In this Renasas platform, since the platform doesn't have PSCI
system suspend, we can only support s2idle and not s2ram. In this case
we don't ask platform to enter some system state whereas we suspend all
the devices(leaving wakeup capable devices active) and ask platform to
enter deepest idle state on all the CPUs. I still don't understand the
issue Geert is facing.

Geert, so far you have failed to explain what's different from the new
state you are adding and the existing s2idle.

> As for the device wakeup disable/enable interface, it is for controlling
> whether or not a given device should be allowed to generate wakeup signals at
> all.
> 
> The information on what states a given device can wake up the system from is
> platform-specific and generally would need to be taken into consideration at
> the platform level.
> 

Exactly, that's what I am trying to convince Geert ;)

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 22/02/17 01:14, Rafael J. Wysocki wrote:
> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:

[...]

>>
>> I take this back, you have everything you need in place, nothing needs
>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>> which is exactly what we need. Again we don't support standby/shallow
>> state on ARM64/PSCI.
> 
> Except for one thing which may or may not be a concern here.
> 
> Suspend to idle should only go into states in which all of the available wakeup
> devices work.  If there are devices that cannot wake you up from a given state,
> this isn't "idle" any more, is it?
> 

True. In this Renasas platform, since the platform doesn't have PSCI
system suspend, we can only support s2idle and not s2ram. In this case
we don't ask platform to enter some system state whereas we suspend all
the devices(leaving wakeup capable devices active) and ask platform to
enter deepest idle state on all the CPUs. I still don't understand the
issue Geert is facing.

Geert, so far you have failed to explain what's different from the new
state you are adding and the existing s2idle.

> As for the device wakeup disable/enable interface, it is for controlling
> whether or not a given device should be allowed to generate wakeup signals at
> all.
> 
> The information on what states a given device can wake up the system from is
> platform-specific and generally would need to be taken into consideration at
> the platform level.
> 

Exactly, that's what I am trying to convince Geert ;)

-- 
Regards,
Sudeep

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

[Geert Uytterhoeven]

Hi Sudeep,

On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>
> [...]
>
>>> I take this back, you have everything you need in place, nothing needs
>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>> which is exactly what we need. Again we don't support standby/shallow
>>> state on ARM64/PSCI.
>>
>> Except for one thing which may or may not be a concern here.
>>
>> Suspend to idle should only go into states in which all of the available wakeup
>> devices work.  If there are devices that cannot wake you up from a given state,
>> this isn't "idle" any more, is it?
>>
>
> True. In this Renasas platform, since the platform doesn't have PSCI
> system suspend, we can only support s2idle and not s2ram. In this case

Not correct: this Renesas platform does have PSCI system suspend.
So s2ram "works" (it suspends the system, which can be resumed by a switch)

> we don't ask platform to enter some system state whereas we suspend all
> the devices(leaving wakeup capable devices active) and ask platform to
> enter deepest idle state on all the CPUs. I still don't understand the
> issue Geert is facing.

PSCI system suspend does not support wake-up sources configured from Linux.
Hence I cannot use PSCI system suspend if any wake-up sources have been
configured from Linux, and I expect to be able to use them for wake-up.

> Geert, so far you have failed to explain what's different from the new
> state you are adding and the existing s2idle.

I did explain, cfr.:
  1. The power consumption figures in the cover letter:
      - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
  2. The description for patch 3/6:
        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.

>> As for the device wakeup disable/enable interface, it is for controlling
>> whether or not a given device should be allowed to generate wakeup signals at
>> all.
>>
>> The information on what states a given device can wake up the system from is
>> platform-specific and generally would need to be taken into consideration at
>> the platform level.
>
> Exactly, that's what I am trying to convince Geert ;)

So, how does the communication of wake-up sources happens between PSCI
and Linux?

Perhaps, I didn't make myself clear. Let's summarize:
  1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
  2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
     wake-up from PMIC only,
  3. If the user wants to use a different wake-up source, these other
wake-up sources fail
     to wake up the system from PSCI SYSTEM_SUSPEND.,
  4. Patch 3/6 adds a new "shallow" state, as it allows to save more
power (the difference
     may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
  5. Patch 4/6 makes the system use the new "shallow" state iff
       a. the user has configured other wake-up sources, and
       b. DT advertises that PSCI will power down the SoC on SYSTEM_SUSPEND,
     hence other wake-up sources now work as expected.

(If you're so against implementing the "shallow" state, it's a red herring,
 and that patch can be dropped.  Patch 4/6 can be trivially modified, as
 all it does is call cpu_do_idle() instead).

E.g. on non-PSCI platforms with an Ethernet driver that supports
Wake-on-LAN, I can do:

        ethtool -s eth0 wol g
        echo mem > /sys/power/state

and be sure that the system can be woken up by sending a WoL MagicPacket.

On PSCI systems, the above may work, or may not work. And there's no way to
find out (in an automated way) whether it will work or not.

If it doesn't work, the user has to configure his system (manually) to
not use "mem" state.
Since v4.10-rc1, that can be done using e.g.

    echo s2idle > /sys/power/mem_sleep

and my patches make that automatic (for a new "shallow" state instead
of "s2idle", though).

So all of this is a usability issue, and a nightmare for userspace
that wants to treat
different platforms in a generic way (e.g. for distros).

I hope this time it's clear what I want to achieve, and how.

Thanks!

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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>
> [...]
>
>>> I take this back, you have everything you need in place, nothing needs
>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>> which is exactly what we need. Again we don't support standby/shallow
>>> state on ARM64/PSCI.
>>
>> Except for one thing which may or may not be a concern here.
>>
>> Suspend to idle should only go into states in which all of the available wakeup
>> devices work.  If there are devices that cannot wake you up from a given state,
>> this isn't "idle" any more, is it?
>>
>
> True. In this Renasas platform, since the platform doesn't have PSCI
> system suspend, we can only support s2idle and not s2ram. In this case

Not correct: this Renesas platform does have PSCI system suspend.
So s2ram "works" (it suspends the system, which can be resumed by a switch)

> we don't ask platform to enter some system state whereas we suspend all
> the devices(leaving wakeup capable devices active) and ask platform to
> enter deepest idle state on all the CPUs. I still don't understand the
> issue Geert is facing.

PSCI system suspend does not support wake-up sources configured from Linux.
Hence I cannot use PSCI system suspend if any wake-up sources have been
configured from Linux, and I expect to be able to use them for wake-up.

> Geert, so far you have failed to explain what's different from the new
> state you are adding and the existing s2idle.

I did explain, cfr.:
  1. The power consumption figures in the cover letter:
      - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
  2. The description for patch 3/6:
        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.

>> As for the device wakeup disable/enable interface, it is for controlling
>> whether or not a given device should be allowed to generate wakeup signals at
>> all.
>>
>> The information on what states a given device can wake up the system from is
>> platform-specific and generally would need to be taken into consideration at
>> the platform level.
>
> Exactly, that's what I am trying to convince Geert ;)

So, how does the communication of wake-up sources happens between PSCI
and Linux?

Perhaps, I didn't make myself clear. Let's summarize:
  1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
  2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
     wake-up from PMIC only,
  3. If the user wants to use a different wake-up source, these other
wake-up sources fail
     to wake up the system from PSCI SYSTEM_SUSPEND.,
  4. Patch 3/6 adds a new "shallow" state, as it allows to save more
power (the difference
     may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
  5. Patch 4/6 makes the system use the new "shallow" state iff
       a. the user has configured other wake-up sources, and
       b. DT advertises that PSCI will power down the SoC on SYSTEM_SUSPEND,
     hence other wake-up sources now work as expected.

(If you're so against implementing the "shallow" state, it's a red herring,
 and that patch can be dropped.  Patch 4/6 can be trivially modified, as
 all it does is call cpu_do_idle() instead).

E.g. on non-PSCI platforms with an Ethernet driver that supports
Wake-on-LAN, I can do:

        ethtool -s eth0 wol g
        echo mem > /sys/power/state

and be sure that the system can be woken up by sending a WoL MagicPacket.

On PSCI systems, the above may work, or may not work. And there's no way to
find out (in an automated way) whether it will work or not.

If it doesn't work, the user has to configure his system (manually) to
not use "mem" state.
Since v4.10-rc1, that can be done using e.g.

    echo s2idle > /sys/power/mem_sleep

and my patches make that automatic (for a new "shallow" state instead
of "s2idle", though).

So all of this is a usability issue, and a nightmare for userspace
that wants to treat
different platforms in a generic way (e.g. for distros).

I hope this time it's clear what I want to achieve, and how.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>
> [...]
>
>>> I take this back, you have everything you need in place, nothing needs
>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>> which is exactly what we need. Again we don't support standby/shallow
>>> state on ARM64/PSCI.
>>
>> Except for one thing which may or may not be a concern here.
>>
>> Suspend to idle should only go into states in which all of the available wakeup
>> devices work.  If there are devices that cannot wake you up from a given state,
>> this isn't "idle" any more, is it?
>>
>
> True. In this Renasas platform, since the platform doesn't have PSCI
> system suspend, we can only support s2idle and not s2ram. In this case

Not correct: this Renesas platform does have PSCI system suspend.
So s2ram "works" (it suspends the system, which can be resumed by a switch)

> we don't ask platform to enter some system state whereas we suspend all
> the devices(leaving wakeup capable devices active) and ask platform to
> enter deepest idle state on all the CPUs. I still don't understand the
> issue Geert is facing.

PSCI system suspend does not support wake-up sources configured from Linux.
Hence I cannot use PSCI system suspend if any wake-up sources have been
configured from Linux, and I expect to be able to use them for wake-up.

> Geert, so far you have failed to explain what's different from the new
> state you are adding and the existing s2idle.

I did explain, cfr.:
  1. The power consumption figures in the cover letter:
      - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
  2. The description for patch 3/6:
        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.

>> As for the device wakeup disable/enable interface, it is for controlling
>> whether or not a given device should be allowed to generate wakeup signals at
>> all.
>>
>> The information on what states a given device can wake up the system from is
>> platform-specific and generally would need to be taken into consideration at
>> the platform level.
>
> Exactly, that's what I am trying to convince Geert ;)

So, how does the communication of wake-up sources happens between PSCI
and Linux?

Perhaps, I didn't make myself clear. Let's summarize:
  1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
  2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
     wake-up from PMIC only,
  3. If the user wants to use a different wake-up source, these other
wake-up sources fail
     to wake up the system from PSCI SYSTEM_SUSPEND.,
  4. Patch 3/6 adds a new "shallow" state, as it allows to save more
power (the difference
     may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
  5. Patch 4/6 makes the system use the new "shallow" state iff
       a. the user has configured other wake-up sources, and
       b. DT advertises that PSCI will power down the SoC on SYSTEM_SUSPEND,
     hence other wake-up sources now work as expected.

(If you're so against implementing the "shallow" state, it's a red herring,
 and that patch can be dropped.  Patch 4/6 can be trivially modified, as
 all it does is call cpu_do_idle() instead).

E.g. on non-PSCI platforms with an Ethernet driver that supports
Wake-on-LAN, I can do:

        ethtool -s eth0 wol g
        echo mem > /sys/power/state

and be sure that the system can be woken up by sending a WoL MagicPacket.

On PSCI systems, the above may work, or may not work. And there's no way to
find out (in an automated way) whether it will work or not.

If it doesn't work, the user has to configure his system (manually) to
not use "mem" state.
Since v4.10-rc1, that can be done using e.g.

    echo s2idle > /sys/power/mem_sleep

and my patches make that automatic (for a new "shallow" state instead
of "s2idle", though).

So all of this is a usability issue, and a nightmare for userspace
that wants to treat
different platforms in a generic way (e.g. for distros).

I hope this time it's clear what I want to achieve, and how.

Thanks!

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

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

[Sudeep Holla]

On 22/02/17 13:38, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>
>> [...]
>>
>>>> I take this back, you have everything you need in place, nothing needs
>>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>>> which is exactly what we need. Again we don't support standby/shallow
>>>> state on ARM64/PSCI.
>>>
>>> Except for one thing which may or may not be a concern here.
>>>
>>> Suspend to idle should only go into states in which all of the available wakeup
>>> devices work.  If there are devices that cannot wake you up from a given state,
>>> this isn't "idle" any more, is it?
>>>
>>
>> True. In this Renasas platform, since the platform doesn't have PSCI
>> system suspend, we can only support s2idle and not s2ram. In this case
> 
> Not correct: this Renesas platform does have PSCI system suspend.
> So s2ram "works" (it suspends the system, which can be resumed by a switch)
> 

Ah OK. Sorry for misunderstanding the platform support.

>> we don't ask platform to enter some system state whereas we suspend all
>> the devices(leaving wakeup capable devices active) and ask platform to
>> enter deepest idle state on all the CPUs. I still don't understand the
>> issue Geert is facing.
> 
> PSCI system suspend does not support wake-up sources configured from Linux.
> Hence I cannot use PSCI system suspend if any wake-up sources have been
> configured from Linux, and I expect to be able to use them for wake-up.
> 

OK, I thought I had told this before. What do you mean by PSCI system
suspend can't wakeup from the configured wakeup source. You just said
above that you can wake up from the switch.

Just enabling the wakeup sources in Linux doesn't mean you can enter
system suspend anytime. You must enter only the state from which you can
resume. And in your case if you can't wakeup from WLAN or wakeup source
you have configured then simply don't enter system suspend.

>> Geert, so far you have failed to explain what's different from the new
>> state you are adding and the existing s2idle.
> 
> I did explain, cfr.:
>   1. The power consumption figures in the cover letter:
>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)

That's because your CPU_SUSPEND implementation is incomplete. You can
enter the same state as secondary CPU core off even with idle. It's just
that we can save by not entering and exiting the CPU hotplug state
machine. So this "shallow" state can be achieved if your CPU_SUSPEND
implements that state.

>   2. The description for patch 3/6:
>         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.
> 

Yes I understood that, you need to add an extra idle states to get that
shallow state. We have discussed this in past to depth. On ARM64/PSCI,
we will that support "shallow" system suspend mode which can't be
defined generically. Also we can support this shallow state with s2idle.

Your system probably not supporting all the CPU idle states. E.g.: it
may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
that state to CPU_SUSPEND implementation in the firmware.

>>> As for the device wakeup disable/enable interface, it is for controlling
>>> whether or not a given device should be allowed to generate wakeup signals at
>>> all.
>>>
>>> The information on what states a given device can wake up the system from is
>>> platform-specific and generally would need to be taken into consideration at
>>> the platform level.
>>
>> Exactly, that's what I am trying to convince Geert ;)
> 
> So, how does the communication of wake-up sources happens between PSCI
> and Linux?
> 
> Perhaps, I didn't make myself clear. Let's summarize:
>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,

OK got that.

>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>      wake-up from PMIC only,

OK

>   3. If the user wants to use a different wake-up source, these other
> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.

In that case don't enter PSCI SYSTEM_SUSPEND

>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),

Why can't you do that in s2idle mode. Please give me the difference
between your shallow state and s2idle state, not just power numbers
but the actual state of CPUs and the devices in the system.

>   5. Patch 4/6 makes the system use the new "shallow" state iff
>        a. the user has configured other wake-up sources, and
>        b. DT advertises that PSCI will power down the SoC on SYSTEM_SUSPEND,
>      hence other wake-up sources now work as expected.
> 

Linux can just leave the wakeup interrupts enabled in the interrupt
controller and the PSCI implementation can understand that. That's what
we mean when we say platform must deal with that. It should not enter
the state blindly if it can't wake up with those sources. It's not
always necessary to communicate such details via dedicated PSCI APIs.
It's impossible and not scalable in a system with 100s of interrupt
sources. Platform can deal with that in better and simple ways than APIs
to exchange such information.

> (If you're so against implementing the "shallow" state, it's a red herring,
>  and that patch can be dropped.  Patch 4/6 can be trivially modified, as
>  all it does is call cpu_do_idle() instead).
> 

And again that's exactly what s2idle implementation. So NACK for each
patch in this series.

> E.g. on non-PSCI platforms with an Ethernet driver that supports
> Wake-on-LAN, I can do:
> 
>         ethtool -s eth0 wol g
>         echo mem > /sys/power/state
> 
> and be sure that the system can be woken up by sending a WoL MagicPacket.
> 

Still possible with s2idle if CPU_SUSPEND is correctly implemented by
the platform.

> On PSCI systems, the above may work, or may not work. And there's no way to
> find out (in an automated way) whether it will work or not.
> 
> If it doesn't work, the user has to configure his system (manually) to
> not use "mem" state.
> Since v4.10-rc1, that can be done using e.g.
> 
>     echo s2idle > /sys/power/mem_sleep
> 
> and my patches make that automatic (for a new "shallow" state instead
> of "s2idle", though).

How is that ? If "deep" is available as in your case too, why will
shallow become default. IIUC the user still have to write "shallow"
to mem_sleep.

Again to re-iterate, we will not support the not so well defined
"shallow" sleep state unless it's proved that the same can't be done
with cpuidle.

> 
> So all of this is a usability issue, and a nightmare for userspace
> that wants to treat different platforms in a generic way (e.g. for distros).
> 

Yes exactly and that's one reason why "shallow" is useless as it's not
well defined or should I say ill-defined.

> I hope this time it's clear what I want to achieve, and how.
> 

Yes, go and fix the CPU_SUSPEND to implement all the idle states correctly.

Does this platform use generic arm64 DT cpuidle driver ? I don't see so
from the DT.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 22/02/17 13:38, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>
>> [...]
>>
>>>> I take this back, you have everything you need in place, nothing needs
>>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>>> which is exactly what we need. Again we don't support standby/shallow
>>>> state on ARM64/PSCI.
>>>
>>> Except for one thing which may or may not be a concern here.
>>>
>>> Suspend to idle should only go into states in which all of the available wakeup
>>> devices work.  If there are devices that cannot wake you up from a given state,
>>> this isn't "idle" any more, is it?
>>>
>>
>> True. In this Renasas platform, since the platform doesn't have PSCI
>> system suspend, we can only support s2idle and not s2ram. In this case
> 
> Not correct: this Renesas platform does have PSCI system suspend.
> So s2ram "works" (it suspends the system, which can be resumed by a switch)
> 

Ah OK. Sorry for misunderstanding the platform support.

>> we don't ask platform to enter some system state whereas we suspend all
>> the devices(leaving wakeup capable devices active) and ask platform to
>> enter deepest idle state on all the CPUs. I still don't understand the
>> issue Geert is facing.
> 
> PSCI system suspend does not support wake-up sources configured from Linux.
> Hence I cannot use PSCI system suspend if any wake-up sources have been
> configured from Linux, and I expect to be able to use them for wake-up.
> 

OK, I thought I had told this before. What do you mean by PSCI system
suspend can't wakeup from the configured wakeup source. You just said
above that you can wake up from the switch.

Just enabling the wakeup sources in Linux doesn't mean you can enter
system suspend anytime. You must enter only the state from which you can
resume. And in your case if you can't wakeup from WLAN or wakeup source
you have configured then simply don't enter system suspend.

>> Geert, so far you have failed to explain what's different from the new
>> state you are adding and the existing s2idle.
> 
> I did explain, cfr.:
>   1. The power consumption figures in the cover letter:
>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)

That's because your CPU_SUSPEND implementation is incomplete. You can
enter the same state as secondary CPU core off even with idle. It's just
that we can save by not entering and exiting the CPU hotplug state
machine. So this "shallow" state can be achieved if your CPU_SUSPEND
implements that state.

>   2. The description for patch 3/6:
>         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.
> 

Yes I understood that, you need to add an extra idle states to get that
shallow state. We have discussed this in past to depth. On ARM64/PSCI,
we will that support "shallow" system suspend mode which can't be
defined generically. Also we can support this shallow state with s2idle.

Your system probably not supporting all the CPU idle states. E.g.: it
may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
that state to CPU_SUSPEND implementation in the firmware.

>>> As for the device wakeup disable/enable interface, it is for controlling
>>> whether or not a given device should be allowed to generate wakeup signals at
>>> all.
>>>
>>> The information on what states a given device can wake up the system from is
>>> platform-specific and generally would need to be taken into consideration at
>>> the platform level.
>>
>> Exactly, that's what I am trying to convince Geert ;)
> 
> So, how does the communication of wake-up sources happens between PSCI
> and Linux?
> 
> Perhaps, I didn't make myself clear. Let's summarize:
>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,

OK got that.

>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>      wake-up from PMIC only,

OK

>   3. If the user wants to use a different wake-up source, these other
> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.

In that case don't enter PSCI SYSTEM_SUSPEND

>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),

Why can't you do that in s2idle mode. Please give me the difference
between your shallow state and s2idle state, not just power numbers
but the actual state of CPUs and the devices in the system.

>   5. Patch 4/6 makes the system use the new "shallow" state iff
>        a. the user has configured other wake-up sources, and
>        b. DT advertises that PSCI will power down the SoC on SYSTEM_SUSPEND,
>      hence other wake-up sources now work as expected.
> 

Linux can just leave the wakeup interrupts enabled in the interrupt
controller and the PSCI implementation can understand that. That's what
we mean when we say platform must deal with that. It should not enter
the state blindly if it can't wake up with those sources. It's not
always necessary to communicate such details via dedicated PSCI APIs.
It's impossible and not scalable in a system with 100s of interrupt
sources. Platform can deal with that in better and simple ways than APIs
to exchange such information.

> (If you're so against implementing the "shallow" state, it's a red herring,
>  and that patch can be dropped.  Patch 4/6 can be trivially modified, as
>  all it does is call cpu_do_idle() instead).
> 

And again that's exactly what s2idle implementation. So NACK for each
patch in this series.

> E.g. on non-PSCI platforms with an Ethernet driver that supports
> Wake-on-LAN, I can do:
> 
>         ethtool -s eth0 wol g
>         echo mem > /sys/power/state
> 
> and be sure that the system can be woken up by sending a WoL MagicPacket.
> 

Still possible with s2idle if CPU_SUSPEND is correctly implemented by
the platform.

> On PSCI systems, the above may work, or may not work. And there's no way to
> find out (in an automated way) whether it will work or not.
> 
> If it doesn't work, the user has to configure his system (manually) to
> not use "mem" state.
> Since v4.10-rc1, that can be done using e.g.
> 
>     echo s2idle > /sys/power/mem_sleep
> 
> and my patches make that automatic (for a new "shallow" state instead
> of "s2idle", though).

How is that ? If "deep" is available as in your case too, why will
shallow become default. IIUC the user still have to write "shallow"
to mem_sleep.

Again to re-iterate, we will not support the not so well defined
"shallow" sleep state unless it's proved that the same can't be done
with cpuidle.

> 
> So all of this is a usability issue, and a nightmare for userspace
> that wants to treat different platforms in a generic way (e.g. for distros).
> 

Yes exactly and that's one reason why "shallow" is useless as it's not
well defined or should I say ill-defined.

> I hope this time it's clear what I want to achieve, and how.
> 

Yes, go and fix the CPU_SUSPEND to implement all the idle states correctly.

Does this platform use generic arm64 DT cpuidle driver ? I don't see so
from the DT.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 22/02/17 13:38, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>
>> [...]
>>
>>>> I take this back, you have everything you need in place, nothing needs
>>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>>> which is exactly what we need. Again we don't support standby/shallow
>>>> state on ARM64/PSCI.
>>>
>>> Except for one thing which may or may not be a concern here.
>>>
>>> Suspend to idle should only go into states in which all of the available wakeup
>>> devices work.  If there are devices that cannot wake you up from a given state,
>>> this isn't "idle" any more, is it?
>>>
>>
>> True. In this Renasas platform, since the platform doesn't have PSCI
>> system suspend, we can only support s2idle and not s2ram. In this case
> 
> Not correct: this Renesas platform does have PSCI system suspend.
> So s2ram "works" (it suspends the system, which can be resumed by a switch)
> 

Ah OK. Sorry for misunderstanding the platform support.

>> we don't ask platform to enter some system state whereas we suspend all
>> the devices(leaving wakeup capable devices active) and ask platform to
>> enter deepest idle state on all the CPUs. I still don't understand the
>> issue Geert is facing.
> 
> PSCI system suspend does not support wake-up sources configured from Linux.
> Hence I cannot use PSCI system suspend if any wake-up sources have been
> configured from Linux, and I expect to be able to use them for wake-up.
> 

OK, I thought I had told this before. What do you mean by PSCI system
suspend can't wakeup from the configured wakeup source. You just said
above that you can wake up from the switch.

Just enabling the wakeup sources in Linux doesn't mean you can enter
system suspend anytime. You must enter only the state from which you can
resume. And in your case if you can't wakeup from WLAN or wakeup source
you have configured then simply don't enter system suspend.

>> Geert, so far you have failed to explain what's different from the new
>> state you are adding and the existing s2idle.
> 
> I did explain, cfr.:
>   1. The power consumption figures in the cover letter:
>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)

That's because your CPU_SUSPEND implementation is incomplete. You can
enter the same state as secondary CPU core off even with idle. It's just
that we can save by not entering and exiting the CPU hotplug state
machine. So this "shallow" state can be achieved if your CPU_SUSPEND
implements that state.

>   2. The description for patch 3/6:
>         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.
> 

Yes I understood that, you need to add an extra idle states to get that
shallow state. We have discussed this in past to depth. On ARM64/PSCI,
we will that support "shallow" system suspend mode which can't be
defined generically. Also we can support this shallow state with s2idle.

Your system probably not supporting all the CPU idle states. E.g.: it
may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
that state to CPU_SUSPEND implementation in the firmware.

>>> As for the device wakeup disable/enable interface, it is for controlling
>>> whether or not a given device should be allowed to generate wakeup signals at
>>> all.
>>>
>>> The information on what states a given device can wake up the system from is
>>> platform-specific and generally would need to be taken into consideration at
>>> the platform level.
>>
>> Exactly, that's what I am trying to convince Geert ;)
> 
> So, how does the communication of wake-up sources happens between PSCI
> and Linux?
> 
> Perhaps, I didn't make myself clear. Let's summarize:
>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,

OK got that.

>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>      wake-up from PMIC only,

OK

>   3. If the user wants to use a different wake-up source, these other
> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.

In that case don't enter PSCI SYSTEM_SUSPEND

>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),

Why can't you do that in s2idle mode. Please give me the difference
between your shallow state and s2idle state, not just power numbers
but the actual state of CPUs and the devices in the system.

>   5. Patch 4/6 makes the system use the new "shallow" state iff
>        a. the user has configured other wake-up sources, and
>        b. DT advertises that PSCI will power down the SoC on SYSTEM_SUSPEND,
>      hence other wake-up sources now work as expected.
> 

Linux can just leave the wakeup interrupts enabled in the interrupt
controller and the PSCI implementation can understand that. That's what
we mean when we say platform must deal with that. It should not enter
the state blindly if it can't wake up with those sources. It's not
always necessary to communicate such details via dedicated PSCI APIs.
It's impossible and not scalable in a system with 100s of interrupt
sources. Platform can deal with that in better and simple ways than APIs
to exchange such information.

> (If you're so against implementing the "shallow" state, it's a red herring,
>  and that patch can be dropped.  Patch 4/6 can be trivially modified, as
>  all it does is call cpu_do_idle() instead).
> 

And again that's exactly what s2idle implementation. So NACK for each
patch in this series.

> E.g. on non-PSCI platforms with an Ethernet driver that supports
> Wake-on-LAN, I can do:
> 
>         ethtool -s eth0 wol g
>         echo mem > /sys/power/state
> 
> and be sure that the system can be woken up by sending a WoL MagicPacket.
> 

Still possible with s2idle if CPU_SUSPEND is correctly implemented by
the platform.

> On PSCI systems, the above may work, or may not work. And there's no way to
> find out (in an automated way) whether it will work or not.
> 
> If it doesn't work, the user has to configure his system (manually) to
> not use "mem" state.
> Since v4.10-rc1, that can be done using e.g.
> 
>     echo s2idle > /sys/power/mem_sleep
> 
> and my patches make that automatic (for a new "shallow" state instead
> of "s2idle", though).

How is that ? If "deep" is available as in your case too, why will
shallow become default. IIUC the user still have to write "shallow"
to mem_sleep.

Again to re-iterate, we will not support the not so well defined
"shallow" sleep state unless it's proved that the same can't be done
with cpuidle.

> 
> So all of this is a usability issue, and a nightmare for userspace
> that wants to treat different platforms in a generic way (e.g. for distros).
> 

Yes exactly and that's one reason why "shallow" is useless as it's not
well defined or should I say ill-defined.

> I hope this time it's clear what I want to achieve, and how.
> 

Yes, go and fix the CPU_SUSPEND to implement all the idle states correctly.

Does this platform use generic arm64 DT cpuidle driver ? I don't see so
from the DT.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 22/02/17 13:38, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>
>> [...]
>>
>>>> I take this back, you have everything you need in place, nothing needs
>>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>>> which is exactly what we need. Again we don't support standby/shallow
>>>> state on ARM64/PSCI.
>>>
>>> Except for one thing which may or may not be a concern here.
>>>
>>> Suspend to idle should only go into states in which all of the available wakeup
>>> devices work.  If there are devices that cannot wake you up from a given state,
>>> this isn't "idle" any more, is it?
>>>
>>
>> True. In this Renasas platform, since the platform doesn't have PSCI
>> system suspend, we can only support s2idle and not s2ram. In this case
> 
> Not correct: this Renesas platform does have PSCI system suspend.
> So s2ram "works" (it suspends the system, which can be resumed by a switch)
> 

Ah OK. Sorry for misunderstanding the platform support.

>> we don't ask platform to enter some system state whereas we suspend all
>> the devices(leaving wakeup capable devices active) and ask platform to
>> enter deepest idle state on all the CPUs. I still don't understand the
>> issue Geert is facing.
> 
> PSCI system suspend does not support wake-up sources configured from Linux.
> Hence I cannot use PSCI system suspend if any wake-up sources have been
> configured from Linux, and I expect to be able to use them for wake-up.
> 

OK, I thought I had told this before. What do you mean by PSCI system
suspend can't wakeup from the configured wakeup source. You just said
above that you can wake up from the switch.

Just enabling the wakeup sources in Linux doesn't mean you can enter
system suspend anytime. You must enter only the state from which you can
resume. And in your case if you can't wakeup from WLAN or wakeup source
you have configured then simply don't enter system suspend.

>> Geert, so far you have failed to explain what's different from the new
>> state you are adding and the existing s2idle.
> 
> I did explain, cfr.:
>   1. The power consumption figures in the cover letter:
>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)

That's because your CPU_SUSPEND implementation is incomplete. You can
enter the same state as secondary CPU core off even with idle. It's just
that we can save by not entering and exiting the CPU hotplug state
machine. So this "shallow" state can be achieved if your CPU_SUSPEND
implements that state.

>   2. The description for patch 3/6:
>         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.
> 

Yes I understood that, you need to add an extra idle states to get that
shallow state. We have discussed this in past to depth. On ARM64/PSCI,
we will that support "shallow" system suspend mode which can't be
defined generically. Also we can support this shallow state with s2idle.

Your system probably not supporting all the CPU idle states. E.g.: it
may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
that state to CPU_SUSPEND implementation in the firmware.

>>> As for the device wakeup disable/enable interface, it is for controlling
>>> whether or not a given device should be allowed to generate wakeup signals at
>>> all.
>>>
>>> The information on what states a given device can wake up the system from is
>>> platform-specific and generally would need to be taken into consideration at
>>> the platform level.
>>
>> Exactly, that's what I am trying to convince Geert ;)
> 
> So, how does the communication of wake-up sources happens between PSCI
> and Linux?
> 
> Perhaps, I didn't make myself clear. Let's summarize:
>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,

OK got that.

>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>      wake-up from PMIC only,

OK

>   3. If the user wants to use a different wake-up source, these other
> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.

In that case don't enter PSCI SYSTEM_SUSPEND

>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),

Why can't you do that in s2idle mode. Please give me the difference
between your shallow state and s2idle state, not just power numbers
but the actual state of CPUs and the devices in the system.

>   5. Patch 4/6 makes the system use the new "shallow" state iff
>        a. the user has configured other wake-up sources, and
>        b. DT advertises that PSCI will power down the SoC on SYSTEM_SUSPEND,
>      hence other wake-up sources now work as expected.
> 

Linux can just leave the wakeup interrupts enabled in the interrupt
controller and the PSCI implementation can understand that. That's what
we mean when we say platform must deal with that. It should not enter
the state blindly if it can't wake up with those sources. It's not
always necessary to communicate such details via dedicated PSCI APIs.
It's impossible and not scalable in a system with 100s of interrupt
sources. Platform can deal with that in better and simple ways than APIs
to exchange such information.

> (If you're so against implementing the "shallow" state, it's a red herring,
>  and that patch can be dropped.  Patch 4/6 can be trivially modified, as
>  all it does is call cpu_do_idle() instead).
> 

And again that's exactly what s2idle implementation. So NACK for each
patch in this series.

> E.g. on non-PSCI platforms with an Ethernet driver that supports
> Wake-on-LAN, I can do:
> 
>         ethtool -s eth0 wol g
>         echo mem > /sys/power/state
> 
> and be sure that the system can be woken up by sending a WoL MagicPacket.
> 

Still possible with s2idle if CPU_SUSPEND is correctly implemented by
the platform.

> On PSCI systems, the above may work, or may not work. And there's no way to
> find out (in an automated way) whether it will work or not.
> 
> If it doesn't work, the user has to configure his system (manually) to
> not use "mem" state.
> Since v4.10-rc1, that can be done using e.g.
> 
>     echo s2idle > /sys/power/mem_sleep
> 
> and my patches make that automatic (for a new "shallow" state instead
> of "s2idle", though).

How is that ? If "deep" is available as in your case too, why will
shallow become default. IIUC the user still have to write "shallow"
to mem_sleep.

Again to re-iterate, we will not support the not so well defined
"shallow" sleep state unless it's proved that the same can't be done
with cpuidle.

> 
> So all of this is a usability issue, and a nightmare for userspace
> that wants to treat different platforms in a generic way (e.g. for distros).
> 

Yes exactly and that's one reason why "shallow" is useless as it's not
well defined or should I say ill-defined.

> I hope this time it's clear what I want to achieve, and how.
> 

Yes, go and fix the CPU_SUSPEND to implement all the idle states correctly.

Does this platform use generic arm64 DT cpuidle driver ? I don't see so
from the DT.

-- 
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/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>>
>>> [...]
>>>
>>>>> I take this back, you have everything you need in place, nothing needs
>>>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>>>> which is exactly what we need. Again we don't support standby/shallow
>>>>> state on ARM64/PSCI.
>>>>
>>>> Except for one thing which may or may not be a concern here.
>>>>
>>>> Suspend to idle should only go into states in which all of the available wakeup
>>>> devices work.  If there are devices that cannot wake you up from a given state,
>>>> this isn't "idle" any more, is it?
>>>>
>>>
>>> True. In this Renasas platform, since the platform doesn't have PSCI
>>> system suspend, we can only support s2idle and not s2ram. In this case
>>
>> Not correct: this Renesas platform does have PSCI system suspend.
>> So s2ram "works" (it suspends the system, which can be resumed by a switch)
>>
>
> Ah OK. Sorry for misunderstanding the platform support.
>
>>> we don't ask platform to enter some system state whereas we suspend all
>>> the devices(leaving wakeup capable devices active) and ask platform to
>>> enter deepest idle state on all the CPUs. I still don't understand the
>>> issue Geert is facing.
>>
>> PSCI system suspend does not support wake-up sources configured from Linux.
>> Hence I cannot use PSCI system suspend if any wake-up sources have been
>> configured from Linux, and I expect to be able to use them for wake-up.
>>
>
> OK, I thought I had told this before. What do you mean by PSCI system
> suspend can't wakeup from the configured wakeup source. You just said
> above that you can wake up from the switch.
>
> Just enabling the wakeup sources in Linux doesn't mean you can enter
> system suspend anytime. You must enter only the state from which you can
> resume. And in your case if you can't wakeup from WLAN or wakeup source
> you have configured then simply don't enter system suspend.

Well, not quite.

The sysfs wakeup setting for devices only means whether or not to
enable the generation of wakeup signals for them while suspending.  It
allows to *prevent* devices from waking up the system, but it doesn't
guarantee that they will actually wake up if enabled.

Now, the platform doesn't decide on the sleep state it will go to on
the basis of what devices have been enabled to wake up the system.
The states ("shallow", "deep") have to be defined upfront, including
what devices can wake up from the "shallow" and what devices can wake
up from the "deep" states (these lists need not be the same).  [As I
said before, the assumption is that all of them will be able to wake
up the system from suspend-to-idle.]

So, if user space triggers a transition to the "shallow" state, say,
it will be possible to wake up the system from it by devices that (a)
can wake it up from the "shallow" state as defined for the given
platform and (b) have been enabled to wake up the system via sysfs.

Conversely, if you have a system power state such that only a subset
of devices can wake up from it, it needs to be defined as either
"shallow" or "deep" and the list of possible wakeup sources is part of
that definition.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>>
>>> [...]
>>>
>>>>> I take this back, you have everything you need in place, nothing needs
>>>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>>>> which is exactly what we need. Again we don't support standby/shallow
>>>>> state on ARM64/PSCI.
>>>>
>>>> Except for one thing which may or may not be a concern here.
>>>>
>>>> Suspend to idle should only go into states in which all of the available wakeup
>>>> devices work.  If there are devices that cannot wake you up from a given state,
>>>> this isn't "idle" any more, is it?
>>>>
>>>
>>> True. In this Renasas platform, since the platform doesn't have PSCI
>>> system suspend, we can only support s2idle and not s2ram. In this case
>>
>> Not correct: this Renesas platform does have PSCI system suspend.
>> So s2ram "works" (it suspends the system, which can be resumed by a switch)
>>
>
> Ah OK. Sorry for misunderstanding the platform support.
>
>>> we don't ask platform to enter some system state whereas we suspend all
>>> the devices(leaving wakeup capable devices active) and ask platform to
>>> enter deepest idle state on all the CPUs. I still don't understand the
>>> issue Geert is facing.
>>
>> PSCI system suspend does not support wake-up sources configured from Linux.
>> Hence I cannot use PSCI system suspend if any wake-up sources have been
>> configured from Linux, and I expect to be able to use them for wake-up.
>>
>
> OK, I thought I had told this before. What do you mean by PSCI system
> suspend can't wakeup from the configured wakeup source. You just said
> above that you can wake up from the switch.
>
> Just enabling the wakeup sources in Linux doesn't mean you can enter
> system suspend anytime. You must enter only the state from which you can
> resume. And in your case if you can't wakeup from WLAN or wakeup source
> you have configured then simply don't enter system suspend.

Well, not quite.

The sysfs wakeup setting for devices only means whether or not to
enable the generation of wakeup signals for them while suspending.  It
allows to *prevent* devices from waking up the system, but it doesn't
guarantee that they will actually wake up if enabled.

Now, the platform doesn't decide on the sleep state it will go to on
the basis of what devices have been enabled to wake up the system.
The states ("shallow", "deep") have to be defined upfront, including
what devices can wake up from the "shallow" and what devices can wake
up from the "deep" states (these lists need not be the same).  [As I
said before, the assumption is that all of them will be able to wake
up the system from suspend-to-idle.]

So, if user space triggers a transition to the "shallow" state, say,
it will be possible to wake up the system from it by devices that (a)
can wake it up from the "shallow" state as defined for the given
platform and (b) have been enabled to wake up the system via sysfs.

Conversely, if you have a system power state such that only a subset
of devices can wake up from it, it needs to be defined as either
"shallow" or "deep" and the list of possible wakeup sources is part of
that definition.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>>
>>> [...]
>>>
>>>>> I take this back, you have everything you need in place, nothing needs
>>>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>>>> which is exactly what we need. Again we don't support standby/shallow
>>>>> state on ARM64/PSCI.
>>>>
>>>> Except for one thing which may or may not be a concern here.
>>>>
>>>> Suspend to idle should only go into states in which all of the available wakeup
>>>> devices work.  If there are devices that cannot wake you up from a given state,
>>>> this isn't "idle" any more, is it?
>>>>
>>>
>>> True. In this Renasas platform, since the platform doesn't have PSCI
>>> system suspend, we can only support s2idle and not s2ram. In this case
>>
>> Not correct: this Renesas platform does have PSCI system suspend.
>> So s2ram "works" (it suspends the system, which can be resumed by a switch)
>>
>
> Ah OK. Sorry for misunderstanding the platform support.
>
>>> we don't ask platform to enter some system state whereas we suspend all
>>> the devices(leaving wakeup capable devices active) and ask platform to
>>> enter deepest idle state on all the CPUs. I still don't understand the
>>> issue Geert is facing.
>>
>> PSCI system suspend does not support wake-up sources configured from Linux.
>> Hence I cannot use PSCI system suspend if any wake-up sources have been
>> configured from Linux, and I expect to be able to use them for wake-up.
>>
>
> OK, I thought I had told this before. What do you mean by PSCI system
> suspend can't wakeup from the configured wakeup source. You just said
> above that you can wake up from the switch.
>
> Just enabling the wakeup sources in Linux doesn't mean you can enter
> system suspend anytime. You must enter only the state from which you can
> resume. And in your case if you can't wakeup from WLAN or wakeup source
> you have configured then simply don't enter system suspend.

Well, not quite.

The sysfs wakeup setting for devices only means whether or not to
enable the generation of wakeup signals for them while suspending.  It
allows to *prevent* devices from waking up the system, but it doesn't
guarantee that they will actually wake up if enabled.

Now, the platform doesn't decide on the sleep state it will go to on
the basis of what devices have been enabled to wake up the system.
The states ("shallow", "deep") have to be defined upfront, including
what devices can wake up from the "shallow" and what devices can wake
up from the "deep" states (these lists need not be the same).  [As I
said before, the assumption is that all of them will be able to wake
up the system from suspend-to-idle.]

So, if user space triggers a transition to the "shallow" state, say,
it will be possible to wake up the system from it by devices that (a)
can wake it up from the "shallow" state as defined for the given
platform and (b) have been enabled to wake up the system via sysfs.

Conversely, if you have a system power state such that only a subset
of devices can wake up from it, it needs to be defined as either
"shallow" or "deep" and the list of possible wakeup sources is part of
that definition.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>
>
> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>>
>>> [...]
>>>
>>>>> I take this back, you have everything you need in place, nothing needs
>>>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>>>> which is exactly what we need. Again we don't support standby/shallow
>>>>> state on ARM64/PSCI.
>>>>
>>>> Except for one thing which may or may not be a concern here.
>>>>
>>>> Suspend to idle should only go into states in which all of the available wakeup
>>>> devices work.  If there are devices that cannot wake you up from a given state,
>>>> this isn't "idle" any more, is it?
>>>>
>>>
>>> True. In this Renasas platform, since the platform doesn't have PSCI
>>> system suspend, we can only support s2idle and not s2ram. In this case
>>
>> Not correct: this Renesas platform does have PSCI system suspend.
>> So s2ram "works" (it suspends the system, which can be resumed by a switch)
>>
>
> Ah OK. Sorry for misunderstanding the platform support.
>
>>> we don't ask platform to enter some system state whereas we suspend all
>>> the devices(leaving wakeup capable devices active) and ask platform to
>>> enter deepest idle state on all the CPUs. I still don't understand the
>>> issue Geert is facing.
>>
>> PSCI system suspend does not support wake-up sources configured from Linux.
>> Hence I cannot use PSCI system suspend if any wake-up sources have been
>> configured from Linux, and I expect to be able to use them for wake-up.
>>
>
> OK, I thought I had told this before. What do you mean by PSCI system
> suspend can't wakeup from the configured wakeup source. You just said
> above that you can wake up from the switch.
>
> Just enabling the wakeup sources in Linux doesn't mean you can enter
> system suspend anytime. You must enter only the state from which you can
> resume. And in your case if you can't wakeup from WLAN or wakeup source
> you have configured then simply don't enter system suspend.

Well, not quite.

The sysfs wakeup setting for devices only means whether or not to
enable the generation of wakeup signals for them while suspending.  It
allows to *prevent* devices from waking up the system, but it doesn't
guarantee that they will actually wake up if enabled.

Now, the platform doesn't decide on the sleep state it will go to on
the basis of what devices have been enabled to wake up the system.
The states ("shallow", "deep") have to be defined upfront, including
what devices can wake up from the "shallow" and what devices can wake
up from the "deep" states (these lists need not be the same).  [As I
said before, the assumption is that all of them will be able to wake
up the system from suspend-to-idle.]

So, if user space triggers a transition to the "shallow" state, say,
it will be possible to wake up the system from it by devices that (a)
can wake it up from the "shallow" state as defined for the given
platform and (b) have been enabled to wake up the system via sysfs.

Conversely, if you have a system power state such that only a subset
of devices can wake up from it, it needs to be defined as either
"shallow" or "deep" and the list of possible wakeup sources is part of
that definition.

Thanks,
Rafael
--
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/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

[Sudeep Holla]

On 22/02/17 14:50, Rafael J. Wysocki wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]

>>
>> OK, I thought I had told this before. What do you mean by PSCI system
>> suspend can't wakeup from the configured wakeup source. You just said
>> above that you can wake up from the switch.
>>
>> Just enabling the wakeup sources in Linux doesn't mean you can enter
>> system suspend anytime. You must enter only the state from which you can
>> resume. And in your case if you can't wakeup from WLAN or wakeup source
>> you have configured then simply don't enter system suspend.
> 
> Well, not quite.
> 
> The sysfs wakeup setting for devices only means whether or not to
> enable the generation of wakeup signals for them while suspending.  It
> allows to *prevent* devices from waking up the system, but it doesn't
> guarantee that they will actually wake up if enabled.
> 
> Now, the platform doesn't decide on the sleep state it will go to on
> the basis of what devices have been enabled to wake up the system.
> The states ("shallow", "deep") have to be defined upfront, including
> what devices can wake up from the "shallow" and what devices can wake
> up from the "deep" states (these lists need not be the same).  [As I
> said before, the assumption is that all of them will be able to wake
> up the system from suspend-to-idle.]
> 
> So, if user space triggers a transition to the "shallow" state, say,
> it will be possible to wake up the system from it by devices that (a)
> can wake it up from the "shallow" state as defined for the given
> platform and (b) have been enabled to wake up the system via sysfs.
> 
> Conversely, if you have a system power state such that only a subset
> of devices can wake up from it, it needs to be defined as either
> "shallow" or "deep" and the list of possible wakeup sources is part of
> that definition.

Completely agreed.

And yes the current assumption is that the set of wake-up source in DT
applies to the suspend-to-idle case and may/may not from the deeper
s2ram state.

Sorry if I conveyed something else in my emails. I was mostly referring
to the patch set and the way it's hacking up. I still fail to understand
what Geert is doing different in his "shallow" state that "s2idle" can't
achieve that state. So my comments were more aligned to that when I made
the above comment.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 22/02/17 14:50, Rafael J. Wysocki wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]

>>
>> OK, I thought I had told this before. What do you mean by PSCI system
>> suspend can't wakeup from the configured wakeup source. You just said
>> above that you can wake up from the switch.
>>
>> Just enabling the wakeup sources in Linux doesn't mean you can enter
>> system suspend anytime. You must enter only the state from which you can
>> resume. And in your case if you can't wakeup from WLAN or wakeup source
>> you have configured then simply don't enter system suspend.
> 
> Well, not quite.
> 
> The sysfs wakeup setting for devices only means whether or not to
> enable the generation of wakeup signals for them while suspending.  It
> allows to *prevent* devices from waking up the system, but it doesn't
> guarantee that they will actually wake up if enabled.
> 
> Now, the platform doesn't decide on the sleep state it will go to on
> the basis of what devices have been enabled to wake up the system.
> The states ("shallow", "deep") have to be defined upfront, including
> what devices can wake up from the "shallow" and what devices can wake
> up from the "deep" states (these lists need not be the same).  [As I
> said before, the assumption is that all of them will be able to wake
> up the system from suspend-to-idle.]
> 
> So, if user space triggers a transition to the "shallow" state, say,
> it will be possible to wake up the system from it by devices that (a)
> can wake it up from the "shallow" state as defined for the given
> platform and (b) have been enabled to wake up the system via sysfs.
> 
> Conversely, if you have a system power state such that only a subset
> of devices can wake up from it, it needs to be defined as either
> "shallow" or "deep" and the list of possible wakeup sources is part of
> that definition.

Completely agreed.

And yes the current assumption is that the set of wake-up source in DT
applies to the suspend-to-idle case and may/may not from the deeper
s2ram state.

Sorry if I conveyed something else in my emails. I was mostly referring
to the patch set and the way it's hacking up. I still fail to understand
what Geert is doing different in his "shallow" state that "s2idle" can't
achieve that state. So my comments were more aligned to that when I made
the above comment.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 22/02/17 14:50, Rafael J. Wysocki wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]

>>
>> OK, I thought I had told this before. What do you mean by PSCI system
>> suspend can't wakeup from the configured wakeup source. You just said
>> above that you can wake up from the switch.
>>
>> Just enabling the wakeup sources in Linux doesn't mean you can enter
>> system suspend anytime. You must enter only the state from which you can
>> resume. And in your case if you can't wakeup from WLAN or wakeup source
>> you have configured then simply don't enter system suspend.
> 
> Well, not quite.
> 
> The sysfs wakeup setting for devices only means whether or not to
> enable the generation of wakeup signals for them while suspending.  It
> allows to *prevent* devices from waking up the system, but it doesn't
> guarantee that they will actually wake up if enabled.
> 
> Now, the platform doesn't decide on the sleep state it will go to on
> the basis of what devices have been enabled to wake up the system.
> The states ("shallow", "deep") have to be defined upfront, including
> what devices can wake up from the "shallow" and what devices can wake
> up from the "deep" states (these lists need not be the same).  [As I
> said before, the assumption is that all of them will be able to wake
> up the system from suspend-to-idle.]
> 
> So, if user space triggers a transition to the "shallow" state, say,
> it will be possible to wake up the system from it by devices that (a)
> can wake it up from the "shallow" state as defined for the given
> platform and (b) have been enabled to wake up the system via sysfs.
> 
> Conversely, if you have a system power state such that only a subset
> of devices can wake up from it, it needs to be defined as either
> "shallow" or "deep" and the list of possible wakeup sources is part of
> that definition.

Completely agreed.

And yes the current assumption is that the set of wake-up source in DT
applies to the suspend-to-idle case and may/may not from the deeper
s2ram state.

Sorry if I conveyed something else in my emails. I was mostly referring
to the patch set and the way it's hacking up. I still fail to understand
what Geert is doing different in his "shallow" state that "s2idle" can't
achieve that state. So my comments were more aligned to that when I made
the above comment.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 22/02/17 14:50, Rafael J. Wysocki wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]

>>
>> OK, I thought I had told this before. What do you mean by PSCI system
>> suspend can't wakeup from the configured wakeup source. You just said
>> above that you can wake up from the switch.
>>
>> Just enabling the wakeup sources in Linux doesn't mean you can enter
>> system suspend anytime. You must enter only the state from which you can
>> resume. And in your case if you can't wakeup from WLAN or wakeup source
>> you have configured then simply don't enter system suspend.
> 
> Well, not quite.
> 
> The sysfs wakeup setting for devices only means whether or not to
> enable the generation of wakeup signals for them while suspending.  It
> allows to *prevent* devices from waking up the system, but it doesn't
> guarantee that they will actually wake up if enabled.
> 
> Now, the platform doesn't decide on the sleep state it will go to on
> the basis of what devices have been enabled to wake up the system.
> The states ("shallow", "deep") have to be defined upfront, including
> what devices can wake up from the "shallow" and what devices can wake
> up from the "deep" states (these lists need not be the same).  [As I
> said before, the assumption is that all of them will be able to wake
> up the system from suspend-to-idle.]
> 
> So, if user space triggers a transition to the "shallow" state, say,
> it will be possible to wake up the system from it by devices that (a)
> can wake it up from the "shallow" state as defined for the given
> platform and (b) have been enabled to wake up the system via sysfs.
> 
> Conversely, if you have a system power state such that only a subset
> of devices can wake up from it, it needs to be defined as either
> "shallow" or "deep" and the list of possible wakeup sources is part of
> that definition.

Completely agreed.

And yes the current assumption is that the set of wake-up source in DT
applies to the suspend-to-idle case and may/may not from the deeper
s2ram state.

Sorry if I conveyed something else in my emails. I was mostly referring
to the patch set and the way it's hacking up. I still fail to understand
what Geert is doing different in his "shallow" state that "s2idle" can't
achieve that state. So my comments were more aligned to that when I made
the above comment.

-- 
Regards,
Sudeep

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

[Geert Uytterhoeven]

Hi Sudeep,

On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>> Geert, so far you have failed to explain what's different from the new
>>> state you are adding and the existing s2idle.
>>
>> I did explain, cfr.:
>>   1. The power consumption figures in the cover letter:
>>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
>
> That's because your CPU_SUSPEND implementation is incomplete. You can
> enter the same state as secondary CPU core off even with idle. It's just
> that we can save by not entering and exiting the CPU hotplug state
> machine. So this "shallow" state can be achieved if your CPU_SUSPEND
> implements that state.

Does that include power areas?

>>   2. The description for patch 3/6:
>>         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.
>
> Yes I understood that, you need to add an extra idle states to get that
> shallow state. We have discussed this in past to depth. On ARM64/PSCI,
> we will that support "shallow" system suspend mode which can't be
> defined generically. Also we can support this shallow state with s2idle.
>
> Your system probably not supporting all the CPU idle states. E.g.: it
> may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
> that state to CPU_SUSPEND implementation in the firmware.

I can find CPU_ON and CPU_OFF in the PSCI specification, but not
CPU_RET?

How is the cluster ON/OFF/RET called exactly? I can't find any CLUSTER_*
calls in the PSCI specification.

>From a quick glance in the PSCI sources, there's some support for powering
down clusters.

>> Perhaps, I didn't make myself clear. Let's summarize:
>>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
>
> OK got that.
>
>>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>>      wake-up from PMIC only,
>
> OK
>
>>   3. If the user wants to use a different wake-up source, these other
>> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.
>
> In that case don't enter PSCI SYSTEM_SUSPEND

Or prevent the system from doing that...

>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>
> Why can't you do that in s2idle mode. Please give me the difference
> between your shallow state and s2idle state, not just power numbers
> but the actual state of CPUs and the devices in the system.

>From the Linux side, there's not much difference, except that the secondary
CPU cores are disabled.  As that is handled by PSCI, the difference may be
in the PSCI implementation.  I will have to check that...

On these SoCs, the individual CPU cores and the SCU/L2 are in separate
(nested) power areas.  Perhaps these power areas are turned off when
disabling the CPU cores, but not when suspending them.

>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>> Wake-on-LAN, I can do:
>>
>>         ethtool -s eth0 wol g
>>         echo mem > /sys/power/state
>>
>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>
> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
> the platform.

Sure. But not automatic, as it needs fiddling with mem_sleep.

>> On PSCI systems, the above may work, or may not work. And there's no way to
>> find out (in an automated way) whether it will work or not.
>>
>> If it doesn't work, the user has to configure his system (manually) to
>> not use "mem" state.
>> Since v4.10-rc1, that can be done using e.g.
>>
>>     echo s2idle > /sys/power/mem_sleep
>>
>> and my patches make that automatic (for a new "shallow" state instead
>> of "s2idle", though).
>
> How is that ? If "deep" is available as in your case too, why will
> shallow become default. IIUC the user still have to write "shallow"
> to mem_sleep.

After patch 4, if needed (DT property + extra wake-up sources configured),
psci_system_suspend_enter() will call cpu_do_idle() instead of
psci_system_suspend(). No need to fiddle with mem_sleep manually.

> Does this platform use generic arm64 DT cpuidle driver ? I don't see so
> from the DT.

I think that task isn't complete yet.

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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>> Geert, so far you have failed to explain what's different from the new
>>> state you are adding and the existing s2idle.
>>
>> I did explain, cfr.:
>>   1. The power consumption figures in the cover letter:
>>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
>
> That's because your CPU_SUSPEND implementation is incomplete. You can
> enter the same state as secondary CPU core off even with idle. It's just
> that we can save by not entering and exiting the CPU hotplug state
> machine. So this "shallow" state can be achieved if your CPU_SUSPEND
> implements that state.

Does that include power areas?

>>   2. The description for patch 3/6:
>>         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.
>
> Yes I understood that, you need to add an extra idle states to get that
> shallow state. We have discussed this in past to depth. On ARM64/PSCI,
> we will that support "shallow" system suspend mode which can't be
> defined generically. Also we can support this shallow state with s2idle.
>
> Your system probably not supporting all the CPU idle states. E.g.: it
> may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
> that state to CPU_SUSPEND implementation in the firmware.

I can find CPU_ON and CPU_OFF in the PSCI specification, but not
CPU_RET?

How is the cluster ON/OFF/RET called exactly? I can't find any CLUSTER_*
calls in the PSCI specification.

>From a quick glance in the PSCI sources, there's some support for powering
down clusters.

>> Perhaps, I didn't make myself clear. Let's summarize:
>>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
>
> OK got that.
>
>>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>>      wake-up from PMIC only,
>
> OK
>
>>   3. If the user wants to use a different wake-up source, these other
>> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.
>
> In that case don't enter PSCI SYSTEM_SUSPEND

Or prevent the system from doing that...

>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>
> Why can't you do that in s2idle mode. Please give me the difference
> between your shallow state and s2idle state, not just power numbers
> but the actual state of CPUs and the devices in the system.

>From the Linux side, there's not much difference, except that the secondary
CPU cores are disabled.  As that is handled by PSCI, the difference may be
in the PSCI implementation.  I will have to check that...

On these SoCs, the individual CPU cores and the SCU/L2 are in separate
(nested) power areas.  Perhaps these power areas are turned off when
disabling the CPU cores, but not when suspending them.

>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>> Wake-on-LAN, I can do:
>>
>>         ethtool -s eth0 wol g
>>         echo mem > /sys/power/state
>>
>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>
> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
> the platform.

Sure. But not automatic, as it needs fiddling with mem_sleep.

>> On PSCI systems, the above may work, or may not work. And there's no way to
>> find out (in an automated way) whether it will work or not.
>>
>> If it doesn't work, the user has to configure his system (manually) to
>> not use "mem" state.
>> Since v4.10-rc1, that can be done using e.g.
>>
>>     echo s2idle > /sys/power/mem_sleep
>>
>> and my patches make that automatic (for a new "shallow" state instead
>> of "s2idle", though).
>
> How is that ? If "deep" is available as in your case too, why will
> shallow become default. IIUC the user still have to write "shallow"
> to mem_sleep.

After patch 4, if needed (DT property + extra wake-up sources configured),
psci_system_suspend_enter() will call cpu_do_idle() instead of
psci_system_suspend(). No need to fiddle with mem_sleep manually.

> Does this platform use generic arm64 DT cpuidle driver ? I don't see so
> from the DT.

I think that task isn't complete yet.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>> Geert, so far you have failed to explain what's different from the new
>>> state you are adding and the existing s2idle.
>>
>> I did explain, cfr.:
>>   1. The power consumption figures in the cover letter:
>>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
>
> That's because your CPU_SUSPEND implementation is incomplete. You can
> enter the same state as secondary CPU core off even with idle. It's just
> that we can save by not entering and exiting the CPU hotplug state
> machine. So this "shallow" state can be achieved if your CPU_SUSPEND
> implements that state.

Does that include power areas?

>>   2. The description for patch 3/6:
>>         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.
>
> Yes I understood that, you need to add an extra idle states to get that
> shallow state. We have discussed this in past to depth. On ARM64/PSCI,
> we will that support "shallow" system suspend mode which can't be
> defined generically. Also we can support this shallow state with s2idle.
>
> Your system probably not supporting all the CPU idle states. E.g.: it
> may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
> that state to CPU_SUSPEND implementation in the firmware.

I can find CPU_ON and CPU_OFF in the PSCI specification, but not
CPU_RET?

How is the cluster ON/OFF/RET called exactly? I can't find any CLUSTER_*
calls in the PSCI specification.

>From a quick glance in the PSCI sources, there's some support for powering
down clusters.

>> Perhaps, I didn't make myself clear. Let's summarize:
>>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
>
> OK got that.
>
>>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>>      wake-up from PMIC only,
>
> OK
>
>>   3. If the user wants to use a different wake-up source, these other
>> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.
>
> In that case don't enter PSCI SYSTEM_SUSPEND

Or prevent the system from doing that...

>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>
> Why can't you do that in s2idle mode. Please give me the difference
> between your shallow state and s2idle state, not just power numbers
> but the actual state of CPUs and the devices in the system.

>From the Linux side, there's not much difference, except that the secondary
CPU cores are disabled.  As that is handled by PSCI, the difference may be
in the PSCI implementation.  I will have to check that...

On these SoCs, the individual CPU cores and the SCU/L2 are in separate
(nested) power areas.  Perhaps these power areas are turned off when
disabling the CPU cores, but not when suspending them.

>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>> Wake-on-LAN, I can do:
>>
>>         ethtool -s eth0 wol g
>>         echo mem > /sys/power/state
>>
>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>
> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
> the platform.

Sure. But not automatic, as it needs fiddling with mem_sleep.

>> On PSCI systems, the above may work, or may not work. And there's no way to
>> find out (in an automated way) whether it will work or not.
>>
>> If it doesn't work, the user has to configure his system (manually) to
>> not use "mem" state.
>> Since v4.10-rc1, that can be done using e.g.
>>
>>     echo s2idle > /sys/power/mem_sleep
>>
>> and my patches make that automatic (for a new "shallow" state instead
>> of "s2idle", though).
>
> How is that ? If "deep" is available as in your case too, why will
> shallow become default. IIUC the user still have to write "shallow"
> to mem_sleep.

After patch 4, if needed (DT property + extra wake-up sources configured),
psci_system_suspend_enter() will call cpu_do_idle() instead of
psci_system_suspend(). No need to fiddle with mem_sleep manually.

> Does this platform use generic arm64 DT cpuidle driver ? I don't see so
> from the DT.

I think that task isn't complete yet.

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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Thu, Feb 23, 2017 at 4:26 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>
>> Why can't you do that in s2idle mode. Please give me the difference
>> between your shallow state and s2idle state, not just power numbers
>> but the actual state of CPUs and the devices in the system.
>
> From the Linux side, there's not much difference, except that the secondary
> CPU cores are disabled.  As that is handled by PSCI, the difference may be
> in the PSCI implementation.  I will have to check that...
>
> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
> (nested) power areas.  Perhaps these power areas are turned off when
> disabling the CPU cores, but not when suspending them.

BTW, I don't care much about the extra state.

>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>> Wake-on-LAN, I can do:
>>>
>>>         ethtool -s eth0 wol g
>>>         echo mem > /sys/power/state
>>>
>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>
>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>> the platform.
>
> Sure. But not automatic, as it needs fiddling with mem_sleep.

I do care about this, as it affects user experience.

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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Thu, Feb 23, 2017 at 4:26 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>
>> Why can't you do that in s2idle mode. Please give me the difference
>> between your shallow state and s2idle state, not just power numbers
>> but the actual state of CPUs and the devices in the system.
>
> From the Linux side, there's not much difference, except that the secondary
> CPU cores are disabled.  As that is handled by PSCI, the difference may be
> in the PSCI implementation.  I will have to check that...
>
> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
> (nested) power areas.  Perhaps these power areas are turned off when
> disabling the CPU cores, but not when suspending them.

BTW, I don't care much about the extra state.

>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>> Wake-on-LAN, I can do:
>>>
>>>         ethtool -s eth0 wol g
>>>         echo mem > /sys/power/state
>>>
>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>
>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>> the platform.
>
> Sure. But not automatic, as it needs fiddling with mem_sleep.

I do care about this, as it affects user experience.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Sudeep,

On Thu, Feb 23, 2017 at 4:26 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>
>> Why can't you do that in s2idle mode. Please give me the difference
>> between your shallow state and s2idle state, not just power numbers
>> but the actual state of CPUs and the devices in the system.
>
> From the Linux side, there's not much difference, except that the secondary
> CPU cores are disabled.  As that is handled by PSCI, the difference may be
> in the PSCI implementation.  I will have to check that...
>
> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
> (nested) power areas.  Perhaps these power areas are turned off when
> disabling the CPU cores, but not when suspending them.

BTW, I don't care much about the extra state.

>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>> Wake-on-LAN, I can do:
>>>
>>>         ethtool -s eth0 wol g
>>>         echo mem > /sys/power/state
>>>
>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>
>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>> the platform.
>
> Sure. But not automatic, as it needs fiddling with mem_sleep.

I do care about this, as it affects user experience.

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

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

[Sudeep Holla]

Hi Geert,

On 23/02/17 15:34, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Thu, Feb 23, 2017 at 4:26 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>>
>>> Why can't you do that in s2idle mode. Please give me the difference
>>> between your shallow state and s2idle state, not just power numbers
>>> but the actual state of CPUs and the devices in the system.
>>
>> From the Linux side, there's not much difference, except that the secondary
>> CPU cores are disabled.  As that is handled by PSCI, the difference may be
>> in the PSCI implementation.  I will have to check that...
>>
>> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
>> (nested) power areas.  Perhaps these power areas are turned off when
>> disabling the CPU cores, but not when suspending them.
> 
> BTW, I don't care much about the extra state.
> 

Then stop caring about extra power usage too ;). Seriously this is not a
valid argument.

>>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>>> Wake-on-LAN, I can do:
>>>>
>>>>         ethtool -s eth0 wol g
>>>>         echo mem > /sys/power/state
>>>>
>>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>>
>>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>>> the platform.
>>
>> Sure. But not automatic, as it needs fiddling with mem_sleep.
> 
> I do care about this, as it affects user experience.
> 

Again when you have both "deep" and "standby" suspend states as per your
patch set, user has to choose one. No escape from that.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

Hi Geert,

On 23/02/17 15:34, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Thu, Feb 23, 2017 at 4:26 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>>
>>> Why can't you do that in s2idle mode. Please give me the difference
>>> between your shallow state and s2idle state, not just power numbers
>>> but the actual state of CPUs and the devices in the system.
>>
>> From the Linux side, there's not much difference, except that the secondary
>> CPU cores are disabled.  As that is handled by PSCI, the difference may be
>> in the PSCI implementation.  I will have to check that...
>>
>> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
>> (nested) power areas.  Perhaps these power areas are turned off when
>> disabling the CPU cores, but not when suspending them.
> 
> BTW, I don't care much about the extra state.
> 

Then stop caring about extra power usage too ;). Seriously this is not a
valid argument.

>>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>>> Wake-on-LAN, I can do:
>>>>
>>>>         ethtool -s eth0 wol g
>>>>         echo mem > /sys/power/state
>>>>
>>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>>
>>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>>> the platform.
>>
>> Sure. But not automatic, as it needs fiddling with mem_sleep.
> 
> I do care about this, as it affects user experience.
> 

Again when you have both "deep" and "standby" suspend states as per your
patch set, user has to choose one. No escape from that.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

Hi Geert,

On 23/02/17 15:34, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Thu, Feb 23, 2017 at 4:26 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>>
>>> Why can't you do that in s2idle mode. Please give me the difference
>>> between your shallow state and s2idle state, not just power numbers
>>> but the actual state of CPUs and the devices in the system.
>>
>> From the Linux side, there's not much difference, except that the secondary
>> CPU cores are disabled.  As that is handled by PSCI, the difference may be
>> in the PSCI implementation.  I will have to check that...
>>
>> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
>> (nested) power areas.  Perhaps these power areas are turned off when
>> disabling the CPU cores, but not when suspending them.
> 
> BTW, I don't care much about the extra state.
> 

Then stop caring about extra power usage too ;). Seriously this is not a
valid argument.

>>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>>> Wake-on-LAN, I can do:
>>>>
>>>>         ethtool -s eth0 wol g
>>>>         echo mem > /sys/power/state
>>>>
>>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>>
>>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>>> the platform.
>>
>> Sure. But not automatic, as it needs fiddling with mem_sleep.
> 
> I do care about this, as it affects user experience.
> 

Again when you have both "deep" and "standby" suspend states as per your
patch set, user has to choose one. No escape from that.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 23/02/17 15:26, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>>> Geert, so far you have failed to explain what's different from the new
>>>> state you are adding and the existing s2idle.
>>>
>>> I did explain, cfr.:
>>>   1. The power consumption figures in the cover letter:
>>>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
>>
>> That's because your CPU_SUSPEND implementation is incomplete. You can
>> enter the same state as secondary CPU core off even with idle. It's just
>> that we can save by not entering and exiting the CPU hotplug state
>> machine. So this "shallow" state can be achieved if your CPU_SUSPEND
>> implements that state.
> 
> Does that include power areas?
> 

OK, I first I didn't understand what you are referring here but I see
some reference further in the email.

>>>   2. The description for patch 3/6:
>>>         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.
>>
>> Yes I understood that, you need to add an extra idle states to get that
>> shallow state. We have discussed this in past to depth. On ARM64/PSCI,
>> we will that support "shallow" system suspend mode which can't be
>> defined generically. Also we can support this shallow state with s2idle.
>>
>> Your system probably not supporting all the CPU idle states. E.g.: it
>> may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
>> that state to CPU_SUSPEND implementation in the firmware.
> 
> I can find CPU_ON and CPU_OFF in the PSCI specification, but not
> CPU_RET?
> 

No, they were just examples of idle states that CPU_SUSPEND call might
support based on what h/w can support on a particular platform.

> How is the cluster ON/OFF/RET called exactly? I can't find any CLUSTER_*
> calls in the PSCI specification.
> 

CPU_SUSPEND with different parameters, just look at the details on
suspend parameters in Section 5.4.2 CPU_SUSPEND parameters: power_state


> From a quick glance in the PSCI sources, there's some support for powering
> down clusters.
> 

Yes, the above section should provide some insight on the same.

>>> Perhaps, I didn't make myself clear. Let's summarize:
>>>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
>>
>> OK got that.
>>
>>>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>>>      wake-up from PMIC only,
>>
>> OK
>>
>>>   3. If the user wants to use a different wake-up source, these other
>>> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.
>>
>> In that case don't enter PSCI SYSTEM_SUSPEND
> 
> Or prevent the system from doing that...
> 

Agreed.

>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>
>> Why can't you do that in s2idle mode. Please give me the difference
>> between your shallow state and s2idle state, not just power numbers
>> but the actual state of CPUs and the devices in the system.
> 
> From the Linux side, there's not much difference, except that the secondary
> CPU cores are disabled.  As that is handled by PSCI, the difference may be
> in the PSCI implementation.  I will have to check that...
> 

Yes it's better to check. I am afraid that both these states will be
same if PSCI implementation is correct and hence we don't want to
support standby suspend mode.

> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
> (nested) power areas.  Perhaps these power areas are turned off when
> disabling the CPU cores, but not when suspending them.
> 

Yes that's what I suspect and hence I said it's incomplete
implementation of CPU_SUSPEND

>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>> Wake-on-LAN, I can do:
>>>
>>>         ethtool -s eth0 wol g
>>>         echo mem > /sys/power/state
>>>
>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>
>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>> the platform.
> 
> Sure. But not automatic, as it needs fiddling with mem_sleep.
> 

Yes that's true form any thing other than "deep" state. i.e. s2idle or
standby. If you are OK to choose standby why not s2idle ?

>>> On PSCI systems, the above may work, or may not work. And there's no way to
>>> find out (in an automated way) whether it will work or not.
>>>
>>> If it doesn't work, the user has to configure his system (manually) to
>>> not use "mem" state.
>>> Since v4.10-rc1, that can be done using e.g.
>>>
>>>     echo s2idle > /sys/power/mem_sleep
>>>
>>> and my patches make that automatic (for a new "shallow" state instead
>>> of "s2idle", though).
>>
>> How is that ? If "deep" is available as in your case too, why will
>> shallow become default. IIUC the user still have to write "shallow"
>> to mem_sleep.
> 
> After patch 4, if needed (DT property + extra wake-up sources configured),
> psci_system_suspend_enter() will call cpu_do_idle() instead of
> psci_system_suspend(). No need to fiddle with mem_sleep manually.
> 

I understand your intentions and but I have NACKed it with sufficient
reasoning. I don't want to repeat them again here.

>> Does this platform use generic arm64 DT cpuidle driver ? I don't see so
>> from the DT.
> 
> I think that task isn't complete yet.
>

So, all these hacks are just to cope up with that ? Sorry that's
non-sense. Working around a firmware bug is different from working
around the incomplete firmware implementation. We may consider former
but for me latter is just insane.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 23/02/17 15:26, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>>> Geert, so far you have failed to explain what's different from the new
>>>> state you are adding and the existing s2idle.
>>>
>>> I did explain, cfr.:
>>>   1. The power consumption figures in the cover letter:
>>>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
>>
>> That's because your CPU_SUSPEND implementation is incomplete. You can
>> enter the same state as secondary CPU core off even with idle. It's just
>> that we can save by not entering and exiting the CPU hotplug state
>> machine. So this "shallow" state can be achieved if your CPU_SUSPEND
>> implements that state.
> 
> Does that include power areas?
> 

OK, I first I didn't understand what you are referring here but I see
some reference further in the email.

>>>   2. The description for patch 3/6:
>>>         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.
>>
>> Yes I understood that, you need to add an extra idle states to get that
>> shallow state. We have discussed this in past to depth. On ARM64/PSCI,
>> we will that support "shallow" system suspend mode which can't be
>> defined generically. Also we can support this shallow state with s2idle.
>>
>> Your system probably not supporting all the CPU idle states. E.g.: it
>> may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
>> that state to CPU_SUSPEND implementation in the firmware.
> 
> I can find CPU_ON and CPU_OFF in the PSCI specification, but not
> CPU_RET?
> 

No, they were just examples of idle states that CPU_SUSPEND call might
support based on what h/w can support on a particular platform.

> How is the cluster ON/OFF/RET called exactly? I can't find any CLUSTER_*
> calls in the PSCI specification.
> 

CPU_SUSPEND with different parameters, just look at the details on
suspend parameters in Section 5.4.2 CPU_SUSPEND parameters: power_state


> From a quick glance in the PSCI sources, there's some support for powering
> down clusters.
> 

Yes, the above section should provide some insight on the same.

>>> Perhaps, I didn't make myself clear. Let's summarize:
>>>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
>>
>> OK got that.
>>
>>>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>>>      wake-up from PMIC only,
>>
>> OK
>>
>>>   3. If the user wants to use a different wake-up source, these other
>>> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.
>>
>> In that case don't enter PSCI SYSTEM_SUSPEND
> 
> Or prevent the system from doing that...
> 

Agreed.

>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>
>> Why can't you do that in s2idle mode. Please give me the difference
>> between your shallow state and s2idle state, not just power numbers
>> but the actual state of CPUs and the devices in the system.
> 
> From the Linux side, there's not much difference, except that the secondary
> CPU cores are disabled.  As that is handled by PSCI, the difference may be
> in the PSCI implementation.  I will have to check that...
> 

Yes it's better to check. I am afraid that both these states will be
same if PSCI implementation is correct and hence we don't want to
support standby suspend mode.

> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
> (nested) power areas.  Perhaps these power areas are turned off when
> disabling the CPU cores, but not when suspending them.
> 

Yes that's what I suspect and hence I said it's incomplete
implementation of CPU_SUSPEND

>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>> Wake-on-LAN, I can do:
>>>
>>>         ethtool -s eth0 wol g
>>>         echo mem > /sys/power/state
>>>
>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>
>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>> the platform.
> 
> Sure. But not automatic, as it needs fiddling with mem_sleep.
> 

Yes that's true form any thing other than "deep" state. i.e. s2idle or
standby. If you are OK to choose standby why not s2idle ?

>>> On PSCI systems, the above may work, or may not work. And there's no way to
>>> find out (in an automated way) whether it will work or not.
>>>
>>> If it doesn't work, the user has to configure his system (manually) to
>>> not use "mem" state.
>>> Since v4.10-rc1, that can be done using e.g.
>>>
>>>     echo s2idle > /sys/power/mem_sleep
>>>
>>> and my patches make that automatic (for a new "shallow" state instead
>>> of "s2idle", though).
>>
>> How is that ? If "deep" is available as in your case too, why will
>> shallow become default. IIUC the user still have to write "shallow"
>> to mem_sleep.
> 
> After patch 4, if needed (DT property + extra wake-up sources configured),
> psci_system_suspend_enter() will call cpu_do_idle() instead of
> psci_system_suspend(). No need to fiddle with mem_sleep manually.
> 

I understand your intentions and but I have NACKed it with sufficient
reasoning. I don't want to repeat them again here.

>> Does this platform use generic arm64 DT cpuidle driver ? I don't see so
>> from the DT.
> 
> I think that task isn't complete yet.
>

So, all these hacks are just to cope up with that ? Sorry that's
non-sense. Working around a firmware bug is different from working
around the incomplete firmware implementation. We may consider former
but for me latter is just insane.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 23/02/17 15:26, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>>> Geert, so far you have failed to explain what's different from the new
>>>> state you are adding and the existing s2idle.
>>>
>>> I did explain, cfr.:
>>>   1. The power consumption figures in the cover letter:
>>>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
>>
>> That's because your CPU_SUSPEND implementation is incomplete. You can
>> enter the same state as secondary CPU core off even with idle. It's just
>> that we can save by not entering and exiting the CPU hotplug state
>> machine. So this "shallow" state can be achieved if your CPU_SUSPEND
>> implements that state.
> 
> Does that include power areas?
> 

OK, I first I didn't understand what you are referring here but I see
some reference further in the email.

>>>   2. The description for patch 3/6:
>>>         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.
>>
>> Yes I understood that, you need to add an extra idle states to get that
>> shallow state. We have discussed this in past to depth. On ARM64/PSCI,
>> we will that support "shallow" system suspend mode which can't be
>> defined generically. Also we can support this shallow state with s2idle.
>>
>> Your system probably not supporting all the CPU idle states. E.g.: it
>> may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
>> that state to CPU_SUSPEND implementation in the firmware.
> 
> I can find CPU_ON and CPU_OFF in the PSCI specification, but not
> CPU_RET?
> 

No, they were just examples of idle states that CPU_SUSPEND call might
support based on what h/w can support on a particular platform.

> How is the cluster ON/OFF/RET called exactly? I can't find any CLUSTER_*
> calls in the PSCI specification.
> 

CPU_SUSPEND with different parameters, just look at the details on
suspend parameters in Section 5.4.2 CPU_SUSPEND parameters: power_state


> From a quick glance in the PSCI sources, there's some support for powering
> down clusters.
> 

Yes, the above section should provide some insight on the same.

>>> Perhaps, I didn't make myself clear. Let's summarize:
>>>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
>>
>> OK got that.
>>
>>>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>>>      wake-up from PMIC only,
>>
>> OK
>>
>>>   3. If the user wants to use a different wake-up source, these other
>>> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.
>>
>> In that case don't enter PSCI SYSTEM_SUSPEND
> 
> Or prevent the system from doing that...
> 

Agreed.

>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>
>> Why can't you do that in s2idle mode. Please give me the difference
>> between your shallow state and s2idle state, not just power numbers
>> but the actual state of CPUs and the devices in the system.
> 
> From the Linux side, there's not much difference, except that the secondary
> CPU cores are disabled.  As that is handled by PSCI, the difference may be
> in the PSCI implementation.  I will have to check that...
> 

Yes it's better to check. I am afraid that both these states will be
same if PSCI implementation is correct and hence we don't want to
support standby suspend mode.

> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
> (nested) power areas.  Perhaps these power areas are turned off when
> disabling the CPU cores, but not when suspending them.
> 

Yes that's what I suspect and hence I said it's incomplete
implementation of CPU_SUSPEND

>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>> Wake-on-LAN, I can do:
>>>
>>>         ethtool -s eth0 wol g
>>>         echo mem > /sys/power/state
>>>
>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>
>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>> the platform.
> 
> Sure. But not automatic, as it needs fiddling with mem_sleep.
> 

Yes that's true form any thing other than "deep" state. i.e. s2idle or
standby. If you are OK to choose standby why not s2idle ?

>>> On PSCI systems, the above may work, or may not work. And there's no way to
>>> find out (in an automated way) whether it will work or not.
>>>
>>> If it doesn't work, the user has to configure his system (manually) to
>>> not use "mem" state.
>>> Since v4.10-rc1, that can be done using e.g.
>>>
>>>     echo s2idle > /sys/power/mem_sleep
>>>
>>> and my patches make that automatic (for a new "shallow" state instead
>>> of "s2idle", though).
>>
>> How is that ? If "deep" is available as in your case too, why will
>> shallow become default. IIUC the user still have to write "shallow"
>> to mem_sleep.
> 
> After patch 4, if needed (DT property + extra wake-up sources configured),
> psci_system_suspend_enter() will call cpu_do_idle() instead of
> psci_system_suspend(). No need to fiddle with mem_sleep manually.
> 

I understand your intentions and but I have NACKed it with sufficient
reasoning. I don't want to repeat them again here.

>> Does this platform use generic arm64 DT cpuidle driver ? I don't see so
>> from the DT.
> 
> I think that task isn't complete yet.
>

So, all these hacks are just to cope up with that ? Sorry that's
non-sense. Working around a firmware bug is different from working
around the incomplete firmware implementation. We may consider former
but for me latter is just insane.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On 23/02/17 15:26, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>>> Geert, so far you have failed to explain what's different from the new
>>>> state you are adding and the existing s2idle.
>>>
>>> I did explain, cfr.:
>>>   1. The power consumption figures in the cover letter:
>>>       - shallow:    8.4 W   6.2 W   (secondary CPU cores off)
>>
>> That's because your CPU_SUSPEND implementation is incomplete. You can
>> enter the same state as secondary CPU core off even with idle. It's just
>> that we can save by not entering and exiting the CPU hotplug state
>> machine. So this "shallow" state can be achieved if your CPU_SUSPEND
>> implements that state.
> 
> Does that include power areas?
> 

OK, I first I didn't understand what you are referring here but I see
some reference further in the email.

>>>   2. The description for patch 3/6:
>>>         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.
>>
>> Yes I understood that, you need to add an extra idle states to get that
>> shallow state. We have discussed this in past to depth. On ARM64/PSCI,
>> we will that support "shallow" system suspend mode which can't be
>> defined generically. Also we can support this shallow state with s2idle.
>>
>> Your system probably not supporting all the CPU idle states. E.g.: it
>> may just support CPU ON/OFF/RET and not cluster ON/OFF/RET. Please add
>> that state to CPU_SUSPEND implementation in the firmware.
> 
> I can find CPU_ON and CPU_OFF in the PSCI specification, but not
> CPU_RET?
> 

No, they were just examples of idle states that CPU_SUSPEND call might
support based on what h/w can support on a particular platform.

> How is the cluster ON/OFF/RET called exactly? I can't find any CLUSTER_*
> calls in the PSCI specification.
> 

CPU_SUSPEND with different parameters, just look at the details on
suspend parameters in Section 5.4.2 CPU_SUSPEND parameters: power_state


> From a quick glance in the PSCI sources, there's some support for powering
> down clusters.
> 

Yes, the above section should provide some insight on the same.

>>> Perhaps, I didn't make myself clear. Let's summarize:
>>>   1. On Renesas R-Car Gen3 platforms, PSCI SYSTEM_SUSPEND is implemented,
>>
>> OK got that.
>>
>>>   2. On these platforms, PSCI SYSTEM_SUSPEND powers down the SoC, and supports
>>>      wake-up from PMIC only,
>>
>> OK
>>
>>>   3. If the user wants to use a different wake-up source, these other
>>> wake-up sources fail to wake up the system from PSCI SYSTEM_SUSPEND.
>>
>> In that case don't enter PSCI SYSTEM_SUSPEND
> 
> Or prevent the system from doing that...
> 

Agreed.

>>>   4. Patch 3/6 adds a new "shallow" state, as it allows to save more
>>> power (the difference may be due to suboptimal cpuidle platform support on R-Car Gen3, though),
>>
>> Why can't you do that in s2idle mode. Please give me the difference
>> between your shallow state and s2idle state, not just power numbers
>> but the actual state of CPUs and the devices in the system.
> 
> From the Linux side, there's not much difference, except that the secondary
> CPU cores are disabled.  As that is handled by PSCI, the difference may be
> in the PSCI implementation.  I will have to check that...
> 

Yes it's better to check. I am afraid that both these states will be
same if PSCI implementation is correct and hence we don't want to
support standby suspend mode.

> On these SoCs, the individual CPU cores and the SCU/L2 are in separate
> (nested) power areas.  Perhaps these power areas are turned off when
> disabling the CPU cores, but not when suspending them.
> 

Yes that's what I suspect and hence I said it's incomplete
implementation of CPU_SUSPEND

>>> E.g. on non-PSCI platforms with an Ethernet driver that supports
>>> Wake-on-LAN, I can do:
>>>
>>>         ethtool -s eth0 wol g
>>>         echo mem > /sys/power/state
>>>
>>> and be sure that the system can be woken up by sending a WoL MagicPacket.
>>
>> Still possible with s2idle if CPU_SUSPEND is correctly implemented by
>> the platform.
> 
> Sure. But not automatic, as it needs fiddling with mem_sleep.
> 

Yes that's true form any thing other than "deep" state. i.e. s2idle or
standby. If you are OK to choose standby why not s2idle ?

>>> On PSCI systems, the above may work, or may not work. And there's no way to
>>> find out (in an automated way) whether it will work or not.
>>>
>>> If it doesn't work, the user has to configure his system (manually) to
>>> not use "mem" state.
>>> Since v4.10-rc1, that can be done using e.g.
>>>
>>>     echo s2idle > /sys/power/mem_sleep
>>>
>>> and my patches make that automatic (for a new "shallow" state instead
>>> of "s2idle", though).
>>
>> How is that ? If "deep" is available as in your case too, why will
>> shallow become default. IIUC the user still have to write "shallow"
>> to mem_sleep.
> 
> After patch 4, if needed (DT property + extra wake-up sources configured),
> psci_system_suspend_enter() will call cpu_do_idle() instead of
> psci_system_suspend(). No need to fiddle with mem_sleep manually.
> 

I understand your intentions and but I have NACKed it with sufficient
reasoning. I don't want to repeat them again here.

>> Does this platform use generic arm64 DT cpuidle driver ? I don't see so
>> from the DT.
> 
> I think that task isn't complete yet.
>

So, all these hacks are just to cope up with that ? Sorry that's
non-sense. Working around a firmware bug is different from working
around the incomplete firmware implementation. We may consider former
but for me latter is just insane.

-- 
Regards,
Sudeep

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

[Geert Uytterhoeven]

Hi Rafael,

On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>> On 21/02/17 18:27, Sudeep Holla wrote:
>> > On 21/02/17 17:51, Sudeep Holla wrote:
>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
>> >>> That's more or less what /sys/power/mem_sleep does, though.
>> >>
>> >> OK, I will go through that in detail.
>> >
>> > OK, I went through the patch and the main intention is was added.
>> > So I will begin by summarizing my understanding:
>> >
>> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
>> > "mem" string in /sys/power/state to represent multiple things that can
>> > be selected.
>> >
>> > Before:
>> > A. echo freeze > /sys/power/state ---> Enters s2idle
>> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
>> >
>> > After:
>> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
>> > 2. echo s2idle > /sys/power/mem_sleep
>> >    echo mem > /sys/power/state ---> Also enter s2idle
>> > 3. echo deep > /sys/power/mem_sleep
>> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
>> >
>> > Please note I have carefully dropped standby/shallow as we will not
>> > support that state on ARM64 platforms(refer previous discussions for the
>> > same)
>> >
>> > Now IIUC, you need 2 above. So, since this new interface allow mem to
>> > mean "s2idle", we need to fix the core to register default suspend_ops
>> > to achieve what you need.
>>
>> I take this back, you have everything you need in place, nothing needs
>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>> which is exactly what we need. Again we don't support standby/shallow
>> state on ARM64/PSCI.
>
> Except for one thing which may or may not be a concern here.
>
> Suspend to idle should only go into states in which all of the available wakeup
> devices work.  If there are devices that cannot wake you up from a given state,
> this isn't "idle" any more, is it?

Indeed. And I have no problem with handling wake-up sources from Linux,
as Linux knows how to handle them.

> As for the device wakeup disable/enable interface, it is for controlling
> whether or not a given device should be allowed to generate wakeup signals at
> all.

OK. So it's not guaranteed that it will actually work...

> The information on what states a given device can wake up the system from is
> platform-specific and generally would need to be taken into consideration at
> the platform level.

So that's PSCI on arm64?
But the PSCI specification doesn't handle that.

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

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

[Geert Uytterhoeven]

Hi Rafael,

On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>> On 21/02/17 18:27, Sudeep Holla wrote:
>> > On 21/02/17 17:51, Sudeep Holla wrote:
>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
>> >>> That's more or less what /sys/power/mem_sleep does, though.
>> >>
>> >> OK, I will go through that in detail.
>> >
>> > OK, I went through the patch and the main intention is was added.
>> > So I will begin by summarizing my understanding:
>> >
>> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
>> > "mem" string in /sys/power/state to represent multiple things that can
>> > be selected.
>> >
>> > Before:
>> > A. echo freeze > /sys/power/state ---> Enters s2idle
>> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
>> >
>> > After:
>> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
>> > 2. echo s2idle > /sys/power/mem_sleep
>> >    echo mem > /sys/power/state ---> Also enter s2idle
>> > 3. echo deep > /sys/power/mem_sleep
>> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
>> >
>> > Please note I have carefully dropped standby/shallow as we will not
>> > support that state on ARM64 platforms(refer previous discussions for the
>> > same)
>> >
>> > Now IIUC, you need 2 above. So, since this new interface allow mem to
>> > mean "s2idle", we need to fix the core to register default suspend_ops
>> > to achieve what you need.
>>
>> I take this back, you have everything you need in place, nothing needs
>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>> which is exactly what we need. Again we don't support standby/shallow
>> state on ARM64/PSCI.
>
> Except for one thing which may or may not be a concern here.
>
> Suspend to idle should only go into states in which all of the available wakeup
> devices work.  If there are devices that cannot wake you up from a given state,
> this isn't "idle" any more, is it?

Indeed. And I have no problem with handling wake-up sources from Linux,
as Linux knows how to handle them.

> As for the device wakeup disable/enable interface, it is for controlling
> whether or not a given device should be allowed to generate wakeup signals at
> all.

OK. So it's not guaranteed that it will actually work...

> The information on what states a given device can wake up the system from is
> platform-specific and generally would need to be taken into consideration at
> the platform level.

So that's PSCI on arm64?
But the PSCI specification doesn't handle that.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

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

[Geert Uytterhoeven]

Hi Rafael,

On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>> On 21/02/17 18:27, Sudeep Holla wrote:
>> > On 21/02/17 17:51, Sudeep Holla wrote:
>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
>> >>> That's more or less what /sys/power/mem_sleep does, though.
>> >>
>> >> OK, I will go through that in detail.
>> >
>> > OK, I went through the patch and the main intention is was added.
>> > So I will begin by summarizing my understanding:
>> >
>> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
>> > "mem" string in /sys/power/state to represent multiple things that can
>> > be selected.
>> >
>> > Before:
>> > A. echo freeze > /sys/power/state ---> Enters s2idle
>> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
>> >
>> > After:
>> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
>> > 2. echo s2idle > /sys/power/mem_sleep
>> >    echo mem > /sys/power/state ---> Also enter s2idle
>> > 3. echo deep > /sys/power/mem_sleep
>> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
>> >
>> > Please note I have carefully dropped standby/shallow as we will not
>> > support that state on ARM64 platforms(refer previous discussions for the
>> > same)
>> >
>> > Now IIUC, you need 2 above. So, since this new interface allow mem to
>> > mean "s2idle", we need to fix the core to register default suspend_ops
>> > to achieve what you need.
>>
>> I take this back, you have everything you need in place, nothing needs
>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>> which is exactly what we need. Again we don't support standby/shallow
>> state on ARM64/PSCI.
>
> Except for one thing which may or may not be a concern here.
>
> Suspend to idle should only go into states in which all of the available wakeup
> devices work.  If there are devices that cannot wake you up from a given state,
> this isn't "idle" any more, is it?

Indeed. And I have no problem with handling wake-up sources from Linux,
as Linux knows how to handle them.

> As for the device wakeup disable/enable interface, it is for controlling
> whether or not a given device should be allowed to generate wakeup signals at
> all.

OK. So it's not guaranteed that it will actually work...

> The information on what states a given device can wake up the system from is
> platform-specific and generally would need to be taken into consideration at
> the platform level.

So that's PSCI on arm64?
But the PSCI specification doesn't handle that.

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

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Rafael,
>
> On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>> On 21/02/17 18:27, Sudeep Holla wrote:
>>> > On 21/02/17 17:51, Sudeep Holla wrote:
>>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
>>> >>> That's more or less what /sys/power/mem_sleep does, though.
>>> >>
>>> >> OK, I will go through that in detail.
>>> >
>>> > OK, I went through the patch and the main intention is was added.
>>> > So I will begin by summarizing my understanding:
>>> >
>>> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
>>> > "mem" string in /sys/power/state to represent multiple things that can
>>> > be selected.
>>> >
>>> > Before:
>>> > A. echo freeze > /sys/power/state ---> Enters s2idle
>>> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
>>> >
>>> > After:
>>> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
>>> > 2. echo s2idle > /sys/power/mem_sleep
>>> >    echo mem > /sys/power/state ---> Also enter s2idle
>>> > 3. echo deep > /sys/power/mem_sleep
>>> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
>>> >
>>> > Please note I have carefully dropped standby/shallow as we will not
>>> > support that state on ARM64 platforms(refer previous discussions for the
>>> > same)
>>> >
>>> > Now IIUC, you need 2 above. So, since this new interface allow mem to
>>> > mean "s2idle", we need to fix the core to register default suspend_ops
>>> > to achieve what you need.
>>>
>>> I take this back, you have everything you need in place, nothing needs
>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>> which is exactly what we need. Again we don't support standby/shallow
>>> state on ARM64/PSCI.
>>
>> Except for one thing which may or may not be a concern here.
>>
>> Suspend to idle should only go into states in which all of the available wakeup
>> devices work.  If there are devices that cannot wake you up from a given state,
>> this isn't "idle" any more, is it?
>
> Indeed. And I have no problem with handling wake-up sources from Linux,
> as Linux knows how to handle them.
>
>> As for the device wakeup disable/enable interface, it is for controlling
>> whether or not a given device should be allowed to generate wakeup signals at
>> all.
>
> OK. So it's not guaranteed that it will actually work...

No, it is not.

Enabling generation of wakeup signals at a device doesn't guarantee
that the interrupt (or GPIO etc) controller will be functional when
those signals reach it, for example.

There actually is no way to guarantee that in general.  In the ACPI
land, for example, devices may be able to wake up the system from S3,
but not from S4 or S5, and you can't say "I want that device to wake
up the system from S4", because that may be physically impossible to
achieve.

>> The information on what states a given device can wake up the system from is
>> platform-specific and generally would need to be taken into consideration at
>> the platform level.
>
> So that's PSCI on arm64?
> But the PSCI specification doesn't handle that.

In theory, that should be some code that knows how the platform is
configured and can set up things to work as expected.

That's why we have all of the platform hooks, syscore operations etc
(of course, all of that is not needed for suspend to idle, because it
is entered via the idle path and wakeup signals for wakeup devices
should be handled then).

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Rafael,
>
> On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>> On 21/02/17 18:27, Sudeep Holla wrote:
>>> > On 21/02/17 17:51, Sudeep Holla wrote:
>>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
>>> >>> That's more or less what /sys/power/mem_sleep does, though.
>>> >>
>>> >> OK, I will go through that in detail.
>>> >
>>> > OK, I went through the patch and the main intention is was added.
>>> > So I will begin by summarizing my understanding:
>>> >
>>> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
>>> > "mem" string in /sys/power/state to represent multiple things that can
>>> > be selected.
>>> >
>>> > Before:
>>> > A. echo freeze > /sys/power/state ---> Enters s2idle
>>> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
>>> >
>>> > After:
>>> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
>>> > 2. echo s2idle > /sys/power/mem_sleep
>>> >    echo mem > /sys/power/state ---> Also enter s2idle
>>> > 3. echo deep > /sys/power/mem_sleep
>>> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
>>> >
>>> > Please note I have carefully dropped standby/shallow as we will not
>>> > support that state on ARM64 platforms(refer previous discussions for the
>>> > same)
>>> >
>>> > Now IIUC, you need 2 above. So, since this new interface allow mem to
>>> > mean "s2idle", we need to fix the core to register default suspend_ops
>>> > to achieve what you need.
>>>
>>> I take this back, you have everything you need in place, nothing needs
>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>> which is exactly what we need. Again we don't support standby/shallow
>>> state on ARM64/PSCI.
>>
>> Except for one thing which may or may not be a concern here.
>>
>> Suspend to idle should only go into states in which all of the available wakeup
>> devices work.  If there are devices that cannot wake you up from a given state,
>> this isn't "idle" any more, is it?
>
> Indeed. And I have no problem with handling wake-up sources from Linux,
> as Linux knows how to handle them.
>
>> As for the device wakeup disable/enable interface, it is for controlling
>> whether or not a given device should be allowed to generate wakeup signals at
>> all.
>
> OK. So it's not guaranteed that it will actually work...

No, it is not.

Enabling generation of wakeup signals at a device doesn't guarantee
that the interrupt (or GPIO etc) controller will be functional when
those signals reach it, for example.

There actually is no way to guarantee that in general.  In the ACPI
land, for example, devices may be able to wake up the system from S3,
but not from S4 or S5, and you can't say "I want that device to wake
up the system from S4", because that may be physically impossible to
achieve.

>> The information on what states a given device can wake up the system from is
>> platform-specific and generally would need to be taken into consideration at
>> the platform level.
>
> So that's PSCI on arm64?
> But the PSCI specification doesn't handle that.

In theory, that should be some code that knows how the platform is
configured and can set up things to work as expected.

That's why we have all of the platform hooks, syscore operations etc
(of course, all of that is not needed for suspend to idle, because it
is entered via the idle path and wakeup signals for wakeup devices
should be handled then).

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Rafael,
>
> On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>> On 21/02/17 18:27, Sudeep Holla wrote:
>>> > On 21/02/17 17:51, Sudeep Holla wrote:
>>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
>>> >>> That's more or less what /sys/power/mem_sleep does, though.
>>> >>
>>> >> OK, I will go through that in detail.
>>> >
>>> > OK, I went through the patch and the main intention is was added.
>>> > So I will begin by summarizing my understanding:
>>> >
>>> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
>>> > "mem" string in /sys/power/state to represent multiple things that can
>>> > be selected.
>>> >
>>> > Before:
>>> > A. echo freeze > /sys/power/state ---> Enters s2idle
>>> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
>>> >
>>> > After:
>>> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
>>> > 2. echo s2idle > /sys/power/mem_sleep
>>> >    echo mem > /sys/power/state ---> Also enter s2idle
>>> > 3. echo deep > /sys/power/mem_sleep
>>> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
>>> >
>>> > Please note I have carefully dropped standby/shallow as we will not
>>> > support that state on ARM64 platforms(refer previous discussions for the
>>> > same)
>>> >
>>> > Now IIUC, you need 2 above. So, since this new interface allow mem to
>>> > mean "s2idle", we need to fix the core to register default suspend_ops
>>> > to achieve what you need.
>>>
>>> I take this back, you have everything you need in place, nothing needs
>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>> which is exactly what we need. Again we don't support standby/shallow
>>> state on ARM64/PSCI.
>>
>> Except for one thing which may or may not be a concern here.
>>
>> Suspend to idle should only go into states in which all of the available wakeup
>> devices work.  If there are devices that cannot wake you up from a given state,
>> this isn't "idle" any more, is it?
>
> Indeed. And I have no problem with handling wake-up sources from Linux,
> as Linux knows how to handle them.
>
>> As for the device wakeup disable/enable interface, it is for controlling
>> whether or not a given device should be allowed to generate wakeup signals at
>> all.
>
> OK. So it's not guaranteed that it will actually work...

No, it is not.

Enabling generation of wakeup signals at a device doesn't guarantee
that the interrupt (or GPIO etc) controller will be functional when
those signals reach it, for example.

There actually is no way to guarantee that in general.  In the ACPI
land, for example, devices may be able to wake up the system from S3,
but not from S4 or S5, and you can't say "I want that device to wake
up the system from S4", because that may be physically impossible to
achieve.

>> The information on what states a given device can wake up the system from is
>> platform-specific and generally would need to be taken into consideration at
>> the platform level.
>
> So that's PSCI on arm64?
> But the PSCI specification doesn't handle that.

In theory, that should be some code that knows how the platform is
configured and can set up things to work as expected.

That's why we have all of the platform hooks, syscore operations etc
(of course, all of that is not needed for suspend to idle, because it
is entered via the idle path and wakeup signals for wakeup devices
should be handled then).

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi Rafael,
>
> On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
>> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:
>>> On 21/02/17 18:27, Sudeep Holla wrote:
>>> > On 21/02/17 17:51, Sudeep Holla wrote:
>>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote:
>>> >>> That's more or less what /sys/power/mem_sleep does, though.
>>> >>
>>> >> OK, I will go through that in detail.
>>> >
>>> > OK, I went through the patch and the main intention is was added.
>>> > So I will begin by summarizing my understanding:
>>> >
>>> > A new suspend interface(/sys/power/mem_sleep) is added to allow the
>>> > "mem" string in /sys/power/state to represent multiple things that can
>>> > be selected.
>>> >
>>> > Before:
>>> > A. echo freeze > /sys/power/state ---> Enters s2idle
>>> > B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)
>>> >
>>> > After:
>>> > 1. echo freeze > /sys/power/state ---> Enters s2idle still same
>>> > 2. echo s2idle > /sys/power/mem_sleep
>>> >    echo mem > /sys/power/state ---> Also enter s2idle
>>> > 3. echo deep > /sys/power/mem_sleep
>>> >    echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)
>>> >
>>> > Please note I have carefully dropped standby/shallow as we will not
>>> > support that state on ARM64 platforms(refer previous discussions for the
>>> > same)
>>> >
>>> > Now IIUC, you need 2 above. So, since this new interface allow mem to
>>> > mean "s2idle", we need to fix the core to register default suspend_ops
>>> > to achieve what you need.
>>>
>>> I take this back, you have everything you need in place, nothing needs
>>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>>> which is exactly what we need. Again we don't support standby/shallow
>>> state on ARM64/PSCI.
>>
>> Except for one thing which may or may not be a concern here.
>>
>> Suspend to idle should only go into states in which all of the available wakeup
>> devices work.  If there are devices that cannot wake you up from a given state,
>> this isn't "idle" any more, is it?
>
> Indeed. And I have no problem with handling wake-up sources from Linux,
> as Linux knows how to handle them.
>
>> As for the device wakeup disable/enable interface, it is for controlling
>> whether or not a given device should be allowed to generate wakeup signals at
>> all.
>
> OK. So it's not guaranteed that it will actually work...

No, it is not.

Enabling generation of wakeup signals at a device doesn't guarantee
that the interrupt (or GPIO etc) controller will be functional when
those signals reach it, for example.

There actually is no way to guarantee that in general.  In the ACPI
land, for example, devices may be able to wake up the system from S3,
but not from S4 or S5, and you can't say "I want that device to wake
up the system from S4", because that may be physically impossible to
achieve.

>> The information on what states a given device can wake up the system from is
>> platform-specific and generally would need to be taken into consideration at
>> the platform level.
>
> So that's PSCI on arm64?
> But the PSCI specification doesn't handle that.

In theory, that should be some code that knows how the platform is
configured and can set up things to work as expected.

That's why we have all of the platform hooks, syscore operations etc
(of course, all of that is not needed for suspend to idle, because it
is entered via the idle path and wakeup signals for wakeup devices
should be handled then).

Thanks,
Rafael
--
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