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, arnd@arndb.de, gregkh@linuxfoundation.org, robh@kernel.org Subject: [PATCH v5 0/3] Introduce SCMI System Power Control driver Date: Thu, 4 Feb 2021 16:59:10 +0000 [thread overview] Message-ID: <20210204165913.42582-1-cristian.marussi@arm.com> (raw) Hi This series, building on top of the recently introduced SCMI System Power Protocol support, adds a new SCMI driver which, registering for SystemPower notifications, acts accordingly to satisfy SCMI plaform system transitions requests like shutdown/reboot both of graceful and forceful kind. (possibly involving userspace when the request is of the graceful kind) Interaction with userspace boils down to the same orderly_ Kernel methods used by ACPI to handle similar shutdown requests. As a part of the series, patch 1/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. The series has been rebased in v5 on top of: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/ since this last series about SCMI modularization carries also a few changes in the SCMI interface exposed to drivers like this one. This whole series, rebased as above specified, can be found (with some messy DEBUG patches on top) at [1]. Thanks Cristian [1]: https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_system_power_control_ext_V5 --- v4 --> v5 - rebased on SCMI Modules v5 series to use new SCMI protocols interface - removed signal based shutdown/reboot - removed all module parameters - added 60secs fixed timeout to shutdwon/reboot requests - make it modularizable to cope with SCMI core modularization - refactored all data config structs - using dev_* instead of pr_* v3 --> v4 - rebased v5.11-rc2 - removed unneeded ugly usage of atomics and barriers - simplfied SysPower shutdown state machine - split out macro definition to different patch v2 --> v3 - rebased - some minor cleanup in codestyle and commit message v1 --> v2 - split out of SCMI System Power Protocol series now merged Cristian Marussi (3): firmware: arm_scmi: support only one single SystemPower device firmware: arm_scmi: add System Power utility macro firmware: arm_scmi: add SCMI System Power Control driver drivers/firmware/Kconfig | 12 + drivers/firmware/arm_scmi/Makefile | 1 + drivers/firmware/arm_scmi/bus.c | 25 ++ .../firmware/arm_scmi/scmi_power_control.c | 347 ++++++++++++++++++ include/linux/scmi_protocol.h | 1 + 5 files changed, 386 insertions(+) create mode 100644 drivers/firmware/arm_scmi/scmi_power_control.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: robh@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org, sudeep.holla@arm.com, lukasz.luba@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, cristian.marussi@arm.com Subject: [PATCH v5 0/3] Introduce SCMI System Power Control driver Date: Thu, 4 Feb 2021 16:59:10 +0000 [thread overview] Message-ID: <20210204165913.42582-1-cristian.marussi@arm.com> (raw) Hi This series, building on top of the recently introduced SCMI System Power Protocol support, adds a new SCMI driver which, registering for SystemPower notifications, acts accordingly to satisfy SCMI plaform system transitions requests like shutdown/reboot both of graceful and forceful kind. (possibly involving userspace when the request is of the graceful kind) Interaction with userspace boils down to the same orderly_ Kernel methods used by ACPI to handle similar shutdown requests. As a part of the series, patch 1/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. The series has been rebased in v5 on top of: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/ since this last series about SCMI modularization carries also a few changes in the SCMI interface exposed to drivers like this one. This whole series, rebased as above specified, can be found (with some messy DEBUG patches on top) at [1]. Thanks Cristian [1]: https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_system_power_control_ext_V5 --- v4 --> v5 - rebased on SCMI Modules v5 series to use new SCMI protocols interface - removed signal based shutdown/reboot - removed all module parameters - added 60secs fixed timeout to shutdwon/reboot requests - make it modularizable to cope with SCMI core modularization - refactored all data config structs - using dev_* instead of pr_* v3 --> v4 - rebased v5.11-rc2 - removed unneeded ugly usage of atomics and barriers - simplfied SysPower shutdown state machine - split out macro definition to different patch v2 --> v3 - rebased - some minor cleanup in codestyle and commit message v1 --> v2 - split out of SCMI System Power Protocol series now merged Cristian Marussi (3): firmware: arm_scmi: support only one single SystemPower device firmware: arm_scmi: add System Power utility macro firmware: arm_scmi: add SCMI System Power Control driver drivers/firmware/Kconfig | 12 + drivers/firmware/arm_scmi/Makefile | 1 + drivers/firmware/arm_scmi/bus.c | 25 ++ .../firmware/arm_scmi/scmi_power_control.c | 347 ++++++++++++++++++ include/linux/scmi_protocol.h | 1 + 5 files changed, 386 insertions(+) create mode 100644 drivers/firmware/arm_scmi/scmi_power_control.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:[~2021-02-04 17:11 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-04 16:59 Cristian Marussi [this message] 2021-02-04 16:59 ` [PATCH v5 0/3] Introduce SCMI System Power Control driver Cristian Marussi 2021-02-04 16:59 ` [PATCH v5 1/3] firmware: arm_scmi: support only one single SystemPower device Cristian Marussi 2021-02-04 16:59 ` Cristian Marussi 2021-02-04 16:59 ` [PATCH v5 2/3] firmware: arm_scmi: add System Power utility macro Cristian Marussi 2021-02-04 16:59 ` Cristian Marussi 2021-02-04 16:59 ` [PATCH v5 3/3] firmware: arm_scmi: add SCMI System Power Control driver Cristian Marussi 2021-02-04 16:59 ` 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=20210204165913.42582-1-cristian.marussi@arm.com \ --to=cristian.marussi@arm.com \ --cc=Jonathan.Cameron@Huawei.com \ --cc=arnd@arndb.de \ --cc=gregkh@linuxfoundation.org \ --cc=james.quinlan@broadcom.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lukasz.luba@arm.com \ --cc=robh@kernel.org \ --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.