Message-ID: <CAL_JsqKV8j8Jm_7B7no6SsZ9AAv=WjqOx9EmCp3fomUXRO-FzQ@mail.gmail.com>
Date:   Tue, 28 Apr 2020 15:18:02 -0500
From:   Rob Herring <robh@...nel.org>
To:     Cristian Marussi <cristian.marussi@....com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        james.quinlan@...adcom.com, Lukasz Luba <lukasz.luba@....com>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [RFC PATCH 0/3] SCMI System Power Support

On Mon, Apr 27, 2020 at 4:08 PM Cristian Marussi
<cristian.marussi@....com> 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
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists