On Tue, 2020-09-29 at 08:29 +0000, Anup Patel wrote:

Hi Greg,

Yes, you are correct. The SBI HART SUSPEND does not have to be state
non-preserving. My previous description about SBI HART SUSPEND was a
bit over simplified.

The ACPI “C-states” are Intel/x86 C-states. The C0-state is similar
to WFI/HINT on RISC-V and for other C-states we can have the SBI HART
SUSPEND call.

Regarding high-level states defined in ARM SBSA, I think
“Idle_retention” and “Sleep” will fall under SBI HART SUSPEND call
for RISC-V.

A parameter to specify exact suspend state to SBI HART SUSPEND call
will be certainly required.

Now we have two things to be defined here:
SBI HSM HART SUSPEND call (with a parameter to specify platform
specific CPU idle power mode)
Discovering supported SBI HART SUSPEND modes for given platform
(Device Tree ?? ACPI ?? SBI Calls ??)

For #2, I think device tree/ACPI would be a better choice. It's already
well defined for ARM. Obviously, it needs to be adopted for RISC-V.

https://elixir.bootlin.com/linux/v5.9-rc7/source/Documentation/devicetree/bindings/arm/idle-states.yaml

Suggestions ??
Any volunteers to propose #1 and #2 above ?

Regards,
Anup

From: Greg Favor <gfavor@...>
Sent: 29 September 2020 06:03
To: Anup Patel <Anup.Patel@...>
Cc: Andrew Waterman <andrew@...>; liush@...;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] Proposal : Hart Suspend
Extension for IDLE

On Sun, Sep 27, 2020 at 2:13 AM Anup Patel <anup.patel@...>
wrote:

We can easily envision following options for S-mode software to
change CPU power mode:
WFI/HINT
SBI HART SUSPEND (with a parameter to specify exact platform
specific CPU idle power mode)
SBI HART STOP

From above, both 2) and 3) will put CPU in a state non-preserving
idle power mode and M-mode firmware will have a platform specific
way to achieve both 2) and 3).

If I remember right, some power management frameworks (e.g. ACPI)
define a series of "C-states" that include both state preserving and
non-preserving sleep states. For the former category, there may be
more than just the "shallow" WFI state, i.e. SBI HART SUSPEND doesn't
necessarily have to be a non-state-preserving power state.

Taking a quick look at the power states defined in ARM SBSA, one has:
- Run
- Idle_standby state-preserving
- Idle_retention state-preserving
- Sleep non-state-preserving
- Off non-state-preserving

In short, the SBI HART SUSPEND parameter would specify different
requested "suspend" power states - some that may preserve state, and
some that may not.

Greg

There is no defined SUSPEND state across architectures and CPU
implementations so 2) will always put CPU in a platform specific
CPU idle power mode. Also, supporting 2) and/or 3) is not mandatory
for any RISC-V platform because M-mode firmware (or Hypervisor) can
always functionally emulate 2) and 3) using a software state
machine.

Generally, the Intel/x86 CPU C-states for CPU idle power management
are used as reference when defining platform specific CPU idle
power modes for option 2) above.

The Linux kernel has very mature CPU idle framework. We just need
to define option 2) considering both x86 and ARM64 as reference so
that RISC-V platforms/vendors have a way to integrate their
platform specific CPU idle power modes.

Regards,
Anup

--
Regards,
Atish