From: Cristian Marussi <cristian.marussi@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: sudeep.holla@arm.com, lukasz.luba@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, cristian.marussi@arm.com Subject: [PATCH v2 0/3] SCMI System Power Support Date: Mon, 4 May 2020 17:55:37 +0100 [thread overview] Message-ID: <20200504165540.37188-1-cristian.marussi@arm.com> (raw) 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. 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. As an alternative method to tunnel graceful requests to userspace it is possible to configure, via available module parameters, a specific signal to be sent to CAD pid. 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. The series is based on SCMI Notifications Core V7 [1] (only posted not merged) which in turn is based on top of scmi-for-next-5.7. Thanks Cristian ---- [1] https://lore.kernel.org/linux-arm-kernel/20200504163855.54548-1-cristian.marussi@arm.com/ 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 | 389 ++++++++++++++++++ drivers/firmware/arm_scmi/system.c | 145 +++++++ include/linux/scmi_protocol.h | 18 + 7 files changed, 571 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
WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Jonathan.Cameron@Huawei.com, cristian.marussi@arm.com, james.quinlan@broadcom.com, lukasz.luba@arm.com, sudeep.holla@arm.com Subject: [PATCH v2 0/3] SCMI System Power Support Date: Mon, 4 May 2020 17:55:37 +0100 [thread overview] Message-ID: <20200504165540.37188-1-cristian.marussi@arm.com> (raw) 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. 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. As an alternative method to tunnel graceful requests to userspace it is possible to configure, via available module parameters, a specific signal to be sent to CAD pid. 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. The series is based on SCMI Notifications Core V7 [1] (only posted not merged) which in turn is based on top of scmi-for-next-5.7. Thanks Cristian ---- [1] https://lore.kernel.org/linux-arm-kernel/20200504163855.54548-1-cristian.marussi@arm.com/ 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 | 389 ++++++++++++++++++ drivers/firmware/arm_scmi/system.c | 145 +++++++ include/linux/scmi_protocol.h | 18 + 7 files changed, 571 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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2020-05-04 16:56 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-04 16:55 Cristian Marussi [this message] 2020-05-04 16:55 ` [PATCH v2 0/3] SCMI System Power Support Cristian Marussi 2020-05-04 16:55 ` [PATCH v2 1/3] firmware: arm_scmi: Add System Power Protocol support Cristian Marussi 2020-05-04 16:55 ` Cristian Marussi 2020-05-04 16:55 ` [PATCH v2 2/3] firmware: arm_scmi: Add SCMI System Power Control driver Cristian Marussi 2020-05-04 16:55 ` Cristian Marussi 2020-05-04 16:55 ` [PATCH v2 3/3] arm64: dts: juno: add SCMI SystemPower Protocol support Cristian Marussi 2020-05-04 16:55 ` Cristian Marussi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200504165540.37188-1-cristian.marussi@arm.com \ --to=cristian.marussi@arm.com \ --cc=Jonathan.Cameron@Huawei.com \ --cc=james.quinlan@broadcom.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lukasz.luba@arm.com \ --cc=sudeep.holla@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.