On Mon, Apr 27, 2020 at 4:08 PM Cristian Marussi <[email protected]> wrote: > > Hi all, > > this series wants to add the core SCMI System Power support and related > events' handling logic: the protocol support itself is trivial and boils > down to some bare initializations and supporting one SCMI System Power > notification event meant to carry platform-originated System transition > requests. This is patch [1/3]. > > On top of this a new SCMI driver has been developed which registers for > such System Power notification and acts accordingly to satisfy such > plaform system-state transition requests that can be of forceful or > graceful kind.
I needed this 7 years ago. :) (hb_keys_notifier in arch/arm/mach-highbank/highbank.c) > In order to comply with such graceful requests, and co-operate with > userspace entities to drive a clean shutdown/reboot, the logic of the > driver relies on the same orderly_* API methods used by ACPI when handling > ACPI Shutdown bus events. This is patch [2/3]. > > Patch [3/3] is a mere JUNO example of the minimal DT bindings needed to > enable the protocol at the DT level and is NOT meant to be upstream as of > now. > > A viable alternative method (not implemented here) for communicating > graceful requests to userspace could be to use instead signals to PID 1 > init process (e.g. kill_cad_pid(SIGRTMIN + 4, 1)): this method is supported > out-of-the-box by SystemD and (to some extent) Android, and, maybe, could > be interesting as an optional alternative, since it avoids the dependency > on usermodehelpers introduced by the internals of the orderly_ API calls > above. > > Such alternative, if deemed worth, should clearly be configurable via DT > (also in terms of which signals to use), BUT all of this work is not done > in this series: and that's the reason for the RFC tag: does it make sense > to add such a configurable additional option ? Which process signal to use in DT? I don't think so. > The series is based on SCMI Notifications Core V7 (still not posted though) > which in turn is based on top of scmi-for-next-5.7 and it's available (with > some additional debug on top) at [1]. > > > Thanks > > Cristian > > ---- > > [1] > http://www.linux-arm.org/git?p=linux-cm.git;a=shortlog;h=refs/heads/scmi_system_power_V1 > > > Cristian Marussi (3): > firmware: arm_scmi: Add System Power Protocol support > firmware: arm_scmi: Add SCMI System Power Control driver > arm64: dts: juno: add SCMI SystemPower Protocol support > > arch/arm64/boot/dts/arm/juno-base.dtsi | 4 + > drivers/firmware/Kconfig | 12 + > drivers/firmware/arm_scmi/Makefile | 3 +- > drivers/firmware/arm_scmi/driver.c | 1 + > .../firmware/arm_scmi/scmi_power_control.c | 359 ++++++++++++++++++ > drivers/firmware/arm_scmi/system.c | 146 +++++++ > include/linux/scmi_protocol.h | 17 + > 7 files changed, 541 insertions(+), 1 deletion(-) > create mode 100644 drivers/firmware/arm_scmi/scmi_power_control.c > create mode 100644 drivers/firmware/arm_scmi/system.c > > -- > 2.17.1 > > > _______________________________________________ > linux-arm-kernel mailing list > [email protected] > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
