[PATCH v3 0/1] riscv: Introduce system suspend support

[PATCH v3 0/1] riscv: Introduce system suspend support

[Andrew Jones]

OpenSBI v1.3 and later supports the SUSP SBI extension which has recently
been frozen with the freezing of SBI 2.0. This one patch series adds
system suspend support to Linux, which implements "suspend-to-RAM". To
use it, build the kernel with CONFIG_SUSPEND, boot on a platform which
supports system suspend, and then issue 'echo mem > /sys/power/state'.
It's also possible to test this Linux support on a platform without
system suspend by using OpenSBI's system suspend test support. To enable
test support add

      opensbi-domains {
          compatible = "opensbi,domain,config";
          system-suspend-test;
      };

to the chosen node of the device tree. With the test node present,
OpenSBI will wait 5 seconds on a suspend and then kick a resume.

Changes for v3:
  - Drop the redundant ARCH_SUSPEND_POSSIBLE addition [Samuel]
    (v1 changed the def_bool to RISCV_SBI, but now it's 'y'
     again. This should be fine since an S-mode Linux will always
     have RISCV_SBI and an M-mode might actually be able to use
     s2idle.)

Changes for v2:
  - Rebase on v6.7-rc1
  - Added check for SBI spec version 2.0, which is the first ratified
    spec version with SUSP [Conor, Anup]
  - Picked up t-b from Samuel

Changes for v1:
  - Rebase on v6.6-rc1 -- only minor Kconfig change needed

Changes for RFC-v2:
  - RISCV_SBI dependency [Conor]
  - Rename SBI_EXT_SUSP_SUSPEND to SBI_EXT_SUSP_SYSTEM_SUSPEND and
    SBI_SUSP_SLEEP_TYPE_SUSPEND to SBI_SUSP_SLEEP_TYPE_SUSPEND_TO_RAM [Ley Foon]


Andrew Jones (1):
  riscv: sbi: Introduce system suspend support

 arch/riscv/Kconfig           |  2 +-
 arch/riscv/include/asm/sbi.h |  9 ++++++++
 arch/riscv/kernel/suspend.c  | 44 ++++++++++++++++++++++++++++++++++++
 3 files changed, 54 insertions(+), 1 deletion(-)

-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 1/1] riscv: sbi: Introduce system suspend support

[Andrew Jones]

When the SUSP SBI extension is present it implies that the standard
"suspend to RAM" type is available. Wire it up to the generic
platform suspend support, also applying the already present support
for non-retentive CPU suspend. When the kernel is built with
CONFIG_SUSPEND, one can do 'echo mem > /sys/power/state' to suspend.
Resumption will occur when a platform-specific wake-up event arrives.

Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
Tested-by: Samuel Holland <samuel.holland@sifive.com>
---
 arch/riscv/Kconfig           |  2 +-
 arch/riscv/include/asm/sbi.h |  9 ++++++++
 arch/riscv/kernel/suspend.c  | 44 ++++++++++++++++++++++++++++++++++++
 3 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 95a2a06acc6a..384a25d5d734 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -65,7 +65,7 @@ config RISCV
 	select CLINT_TIMER if !MMU
 	select CLONE_BACKWARDS
 	select COMMON_CLK
-	select CPU_PM if CPU_IDLE || HIBERNATION
+	select CPU_PM if CPU_IDLE || HIBERNATION || SUSPEND
 	select EDAC_SUPPORT
 	select FRAME_POINTER if PERF_EVENTS || (FUNCTION_TRACER && !DYNAMIC_FTRACE)
 	select GENERIC_ARCH_TOPOLOGY
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 0892f4421bc4..f09356e187df 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -29,6 +29,7 @@ enum sbi_ext_id {
 	SBI_EXT_RFENCE = 0x52464E43,
 	SBI_EXT_HSM = 0x48534D,
 	SBI_EXT_SRST = 0x53525354,
+	SBI_EXT_SUSP = 0x53555350,
 	SBI_EXT_PMU = 0x504D55,
 	SBI_EXT_DBCN = 0x4442434E,
 
@@ -114,6 +115,14 @@ enum sbi_srst_reset_reason {
 	SBI_SRST_RESET_REASON_SYS_FAILURE,
 };
 
+enum sbi_ext_susp_fid {
+	SBI_EXT_SUSP_SYSTEM_SUSPEND = 0,
+};
+
+enum sbi_ext_susp_sleep_type {
+	SBI_SUSP_SLEEP_TYPE_SUSPEND_TO_RAM = 0,
+};
+
 enum sbi_ext_pmu_fid {
 	SBI_EXT_PMU_NUM_COUNTERS = 0,
 	SBI_EXT_PMU_COUNTER_GET_INFO,
diff --git a/arch/riscv/kernel/suspend.c b/arch/riscv/kernel/suspend.c
index 3c89b8ec69c4..239509367e42 100644
--- a/arch/riscv/kernel/suspend.c
+++ b/arch/riscv/kernel/suspend.c
@@ -4,8 +4,12 @@
  * Copyright (c) 2022 Ventana Micro Systems Inc.
  */
 
+#define pr_fmt(fmt) "suspend: " fmt
+
 #include <linux/ftrace.h>
+#include <linux/suspend.h>
 #include <asm/csr.h>
+#include <asm/sbi.h>
 #include <asm/suspend.h>
 
 void suspend_save_csrs(struct suspend_context *context)
@@ -85,3 +89,43 @@ int cpu_suspend(unsigned long arg,
 
 	return rc;
 }
+
+#ifdef CONFIG_RISCV_SBI
+static int sbi_system_suspend(unsigned long sleep_type,
+			      unsigned long resume_addr,
+			      unsigned long opaque)
+{
+	struct sbiret ret;
+
+	ret = sbi_ecall(SBI_EXT_SUSP, SBI_EXT_SUSP_SYSTEM_SUSPEND,
+			sleep_type, resume_addr, opaque, 0, 0, 0);
+	if (ret.error)
+		return sbi_err_map_linux_errno(ret.error);
+
+	return ret.value;
+}
+
+static int sbi_system_suspend_enter(suspend_state_t state)
+{
+	return cpu_suspend(SBI_SUSP_SLEEP_TYPE_SUSPEND_TO_RAM, sbi_system_suspend);
+}
+
+static const struct platform_suspend_ops sbi_system_suspend_ops = {
+	.valid = suspend_valid_only_mem,
+	.enter = sbi_system_suspend_enter,
+};
+
+static int __init sbi_system_suspend_init(void)
+{
+	if (sbi_spec_version >= sbi_mk_version(2, 0) &&
+	    sbi_probe_extension(SBI_EXT_SUSP) > 0) {
+		pr_info("SBI SUSP extension detected\n");
+		if (IS_ENABLED(CONFIG_SUSPEND))
+			suspend_set_ops(&sbi_system_suspend_ops);
+	}
+
+	return 0;
+}
+
+arch_initcall(sbi_system_suspend_init);
+#endif /* CONFIG_RISCV_SBI */
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 1/1] riscv: sbi: Introduce system suspend support

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2276 bytes --]

On Wed, Dec 06, 2023 at 12:08:09PM +0100, Andrew Jones wrote:
> When the SUSP SBI extension is present it implies that the standard
> "suspend to RAM" type is available. Wire it up to the generic
> platform suspend support, also applying the already present support
> for non-retentive CPU suspend. When the kernel is built with
> CONFIG_SUSPEND, one can do 'echo mem > /sys/power/state' to suspend.
> Resumption will occur when a platform-specific wake-up event arrives.
> 
> Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> Tested-by: Samuel Holland <samuel.holland@sifive.com>

> +#ifdef CONFIG_RISCV_SBI
> +static int sbi_system_suspend(unsigned long sleep_type,
> +			      unsigned long resume_addr,
> +			      unsigned long opaque)
> +{
> +	struct sbiret ret;
> +
> +	ret = sbi_ecall(SBI_EXT_SUSP, SBI_EXT_SUSP_SYSTEM_SUSPEND,
> +			sleep_type, resume_addr, opaque, 0, 0, 0);
> +	if (ret.error)
> +		return sbi_err_map_linux_errno(ret.error);
> +
> +	return ret.value;
> +}
> +
> +static int sbi_system_suspend_enter(suspend_state_t state)
> +{
> +	return cpu_suspend(SBI_SUSP_SLEEP_TYPE_SUSPEND_TO_RAM, sbi_system_suspend);
> +}
> +
> +static const struct platform_suspend_ops sbi_system_suspend_ops = {
> +	.valid = suspend_valid_only_mem,
> +	.enter = sbi_system_suspend_enter,
> +};
> +
> +static int __init sbi_system_suspend_init(void)
> +{
> +	if (sbi_spec_version >= sbi_mk_version(2, 0) &&
> +	    sbi_probe_extension(SBI_EXT_SUSP) > 0) {
> +		pr_info("SBI SUSP extension detected\n");

Is there any value in probing and printing this stuff out if
the kernel is not actually built with support for suspend?
I can see either that or moving the IS_ENABLED() check so that
it controls whether we even probe for SUSP being valid so
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Cheers,
Conor.

> +		if (IS_ENABLED(CONFIG_SUSPEND))
> +			suspend_set_ops(&sbi_system_suspend_ops);
> +	}
> +
> +	return 0;
> +}
> +
> +arch_initcall(sbi_system_suspend_init);
> +#endif /* CONFIG_RISCV_SBI */
> -- 
> 2.43.0
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 1/1] riscv: sbi: Introduce system suspend support

[Andrew Jones]

On Wed, Dec 06, 2023 at 12:23:16PM +0000, Conor Dooley wrote:
> On Wed, Dec 06, 2023 at 12:08:09PM +0100, Andrew Jones wrote:
> > When the SUSP SBI extension is present it implies that the standard
> > "suspend to RAM" type is available. Wire it up to the generic
> > platform suspend support, also applying the already present support
> > for non-retentive CPU suspend. When the kernel is built with
> > CONFIG_SUSPEND, one can do 'echo mem > /sys/power/state' to suspend.
> > Resumption will occur when a platform-specific wake-up event arrives.
> > 
> > Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
> > Tested-by: Samuel Holland <samuel.holland@sifive.com>
> 
> > +#ifdef CONFIG_RISCV_SBI
> > +static int sbi_system_suspend(unsigned long sleep_type,
> > +			      unsigned long resume_addr,
> > +			      unsigned long opaque)
> > +{
> > +	struct sbiret ret;
> > +
> > +	ret = sbi_ecall(SBI_EXT_SUSP, SBI_EXT_SUSP_SYSTEM_SUSPEND,
> > +			sleep_type, resume_addr, opaque, 0, 0, 0);
> > +	if (ret.error)
> > +		return sbi_err_map_linux_errno(ret.error);
> > +
> > +	return ret.value;
> > +}
> > +
> > +static int sbi_system_suspend_enter(suspend_state_t state)
> > +{
> > +	return cpu_suspend(SBI_SUSP_SLEEP_TYPE_SUSPEND_TO_RAM, sbi_system_suspend);
> > +}
> > +
> > +static const struct platform_suspend_ops sbi_system_suspend_ops = {
> > +	.valid = suspend_valid_only_mem,
> > +	.enter = sbi_system_suspend_enter,
> > +};
> > +
> > +static int __init sbi_system_suspend_init(void)
> > +{
> > +	if (sbi_spec_version >= sbi_mk_version(2, 0) &&
> > +	    sbi_probe_extension(SBI_EXT_SUSP) > 0) {
> > +		pr_info("SBI SUSP extension detected\n");
> 
> Is there any value in probing and printing this stuff out if
> the kernel is not actually built with support for suspend?

My thinking is that the info message is like those in sbi_init(), which
just state what it sees, whether the kernel wants to use it or not (and
maybe somebody will read the message and choose to recompile with SUSPEND
to enable it...)

> I can see either that or moving the IS_ENABLED() check so that
> it controls whether we even probe for SUSP being valid so
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
drew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 0/1] riscv: Introduce system suspend support

[patchwork-bot+linux-riscv]

Hello:

This patch was applied to riscv/linux.git (for-next)
by Palmer Dabbelt <palmer@rivosinc.com>:

On Wed,  6 Dec 2023 12:08:08 +0100 you wrote:
> OpenSBI v1.3 and later supports the SUSP SBI extension which has recently
> been frozen with the freezing of SBI 2.0. This one patch series adds
> system suspend support to Linux, which implements "suspend-to-RAM". To
> use it, build the kernel with CONFIG_SUSPEND, boot on a platform which
> supports system suspend, and then issue 'echo mem > /sys/power/state'.
> It's also possible to test this Linux support on a platform without
> system suspend by using OpenSBI's system suspend test support. To enable
> test support add
> 
> [...]

Here is the summary with links:
  - [v3,1/1] riscv: sbi: Introduce system suspend support
    https://git.kernel.org/riscv/c/99cc514d444c

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv