mbox series

[0/5] Introduce SCMI System Power Control driver

Message ID 20220623124742.2492164-1-cristian.marussi@arm.com (mailing list archive)
Headers show
Series Introduce SCMI System Power Control driver | expand

Message

Cristian Marussi June 23, 2022, 12:47 p.m. UTC 
Hi,

This series is a respin of an old series[0] parked for a while waiting for
a required SCMI specification change to be published.

The series, building on top of the SCMI System Power Protocol, adds a new 
SCMI driver which, registering for SystemPower notifications, takes care to
satisfy SCMI plaform system-transitions graceful requests like shutdown or
reboot involving userspace interactions as needed.

Interaction with userspace boils down to the same orderly_ Kernel methods
used by ACPI to handle similar shutdown requests.

The latest SCMI v3.1 specification [1], which adds a new timeout field to
the graceful notifications payload, let the platform advertise for how long
it will possibly wait for the requested system state transition to happen
before forcibly enforcing it.

As a part of the series, patch 2/3 enforces, at the SCMI core level, the
creation of one single SCMI SystemPower device, to avoid promoting the
design of systems in which multiple SCMI platforms can advertise the
concurrent support of SystemPower protocol: when multiple SCMI platform
are defined, only one of them should be in charge of SystemPower comms
with the OSPM, so only one such SystemPower device across all platforms
is allowed to be created.

Thanks,
Cristian

[0]:https://lore.kernel.org/linux-arm-kernel/20210204165913.42582-1-cristian.marussi@arm.com/
[1]:https://developer.arm.com/documentation/den0056/d/?lang=en

Cristian Marussi (5):
  firmware: arm_scmi: Remove deprecated ida_simple_ calls
  firmware: arm_scmi: Support only one single SystemPower device
  firmware: arm_scmi: Add SCMIv3.1 SystemPower extensions
  firmware: arm_scmi: Add devm_protocol_acquire helper
  firmware: arm_scmi: Add SCMI System Power Control driver

 drivers/firmware/arm_scmi/Kconfig             |  12 +
 drivers/firmware/arm_scmi/Makefile            |   1 +
 drivers/firmware/arm_scmi/bus.c               |  37 +-
 drivers/firmware/arm_scmi/driver.c            |  70 +++-
 .../firmware/arm_scmi/scmi_power_control.c    | 362 ++++++++++++++++++
 drivers/firmware/arm_scmi/system.c            |  17 +-
 include/linux/scmi_protocol.h                 |   7 +
 7 files changed, 486 insertions(+), 20 deletions(-)
 create mode 100644 drivers/firmware/arm_scmi/scmi_power_control.c

Comments

Sudeep Holla July 1, 2022, 1:49 p.m. UTC | #1 
On Thu, Jun 23, 2022 at 01:47:37PM +0100, Cristian Marussi wrote:
> Hi,
> 
> This series is a respin of an old series[0] parked for a while waiting for
> a required SCMI specification change to be published.
> 
> The series, building on top of the SCMI System Power Protocol, adds a new 
> SCMI driver which, registering for SystemPower notifications, takes care to
> satisfy SCMI plaform system-transitions graceful requests like shutdown or
> reboot involving userspace interactions as needed.
> 
> Interaction with userspace boils down to the same orderly_ Kernel methods
> used by ACPI to handle similar shutdown requests.
> 
> The latest SCMI v3.1 specification [1], which adds a new timeout field to
> the graceful notifications payload, let the platform advertise for how long
> it will possibly wait for the requested system state transition to happen
> before forcibly enforcing it.
> 
> As a part of the series, patch 2/3 enforces, at the SCMI core level, the
> creation of one single SCMI SystemPower device, to avoid promoting the
> design of systems in which multiple SCMI platforms can advertise the
> concurrent support of SystemPower protocol: when multiple SCMI platform
> are defined, only one of them should be in charge of SystemPower comms
> with the OSPM, so only one such SystemPower device across all platforms
> is allowed to be created.
> 

Other than the comment in 2/5, I am happy with the other changes.