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, f.fainelli@gmail.com, etienne.carriere@linaro.org, thara.gopinath@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, cristian.marussi@arm.com Subject: [PATCH 00/11] SCMI vendor protocols and modularization Date: Wed, 14 Oct 2020 16:05:34 +0100 [thread overview] Message-ID: <20201014150545.44807-1-cristian.marussi@arm.com> (raw) Hi all, The current SCMI implementation does not provide an interface to easily develop and include a custom vendor protocol implementation as prescribed by the SCMI standard, also because, there is not currently any custom protocol in the upstream to justify the development of a custom interface and its maintenance. Moreover the current interface exposes protocol operations to the SCMI driver users attaching per-protocol operations directly to the handle structure, which, in this way, tends to grow indefinitely for each new protocol addition. Beside this, protocols private data are also exposed via handle *_priv pointers, making such private data accessible also to the SCMI drivers even if neither really needed nor advisable. Patches 1,2,3 try to address this simplifying the SCMI protocols interface and reducing it to these common generic operations: handle->get_ops() / handle->put_ops() / handle->notify_ops() All protocols' private data pointers are removed from handle too and made accessible only to the protocols code through dedicated internal helpers. Moreover protocol initialization is moved away from device probe and now happens on demand when the first user shows up (first .get_ops), while de-initialization is performed once the last user of the protocol (even in terms of notifications) is gone, with the SCMI core taking care to perform all the needed underlying resource accounting. This way any new future standard or custom protocol implementation will expose a common unified interface which does not need to be extended endlessly: no need to maintain a custom interface only for vendor protos. SCMI drivers written on top of standard or custom protocols will use this same common interface to access any protocol operations. All existent upstream SCMI drivers are converted to this new interface in patch 3. Leveraging this new centralized and common initialization flow, patches 4,5 take care to refactor and simplify protocol-events registration and remove also *notify_priv from the handle interface making it accessible only to the notification core. Finally, patch 6 builds on top of this new interface and introduces a mechanism to define an SCMI protocol as a full blown module (possibly loadable) while leaving the core dealing with proper resource accounting. Moreover protocol initialization is further modified to receive dynamically a pointer to core scmi_xfer_ops at init time, so avoiding to have to export all those xfer symbols in order to make the core transfer methods available to an SCMI protocol dynamically loaded. Standard protocols are still kept as builtins, though. Patches 7-11 are marked [DEBUG] and not meant for for upstreaming but just to be used as an example of how to use all of the above madness to develop a custom dummy vendor protocol module and a related SCMI custom dummy driver. (with all related DT entry/devname). The series is currently based on for-next/scmi [1] on top of: commit fd7c58ee3026 ("firmware: arm_scmi: Fix locking in notifications") Any feedback welcome. Thanks, Cristian [1]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi Cristian Marussi (11): firmware: arm_scmi: review protocol registration interface firmware: arm_scmi: hide protocols' private data firmware: arm_scmi: introduce common protocol interface firmware: arm_scmi: refactor events registration firmware: arm_scmi: make notify_priv really private firmware: arm_scmi: add support for protocol modularization [DEBUG] firmware: arm_scmi: add example custom protocol [DEBUG] arm64: dts: juno: add example custom protocol support [DEBUG] firmware: arm_scmi: add example SCMI driver for custom protocol [DEBUG] firmware: arm_scmi: add custom_dummy SCMI devname [DEBUG][HACK] firmware: arm_scmi: force implemented protocol 0x99 arch/arm64/boot/dts/arm/juno-base.dtsi | 4 + drivers/clk/clk-scmi.c | 30 +- drivers/cpufreq/scmi-cpufreq.c | 28 +- drivers/firmware/Kconfig | 17 +- drivers/firmware/arm_scmi/Makefile | 5 + drivers/firmware/arm_scmi/base.c | 79 +++-- drivers/firmware/arm_scmi/bus.c | 71 +++-- drivers/firmware/arm_scmi/clock.c | 72 +++-- drivers/firmware/arm_scmi/common.h | 73 ++++- drivers/firmware/arm_scmi/driver.c | 292 +++++++++++++++++- drivers/firmware/arm_scmi/notify.c | 171 ++++++---- drivers/firmware/arm_scmi/notify.h | 30 +- drivers/firmware/arm_scmi/perf.c | 135 ++++---- drivers/firmware/arm_scmi/power.c | 85 +++-- drivers/firmware/arm_scmi/reset.c | 87 ++++-- drivers/firmware/arm_scmi/scmi_custom.c | 170 ++++++++++ drivers/firmware/arm_scmi/scmi_custom_dummy.c | 126 ++++++++ drivers/firmware/arm_scmi/scmi_pm_domain.c | 29 +- drivers/firmware/arm_scmi/sensors.c | 92 ++++-- drivers/firmware/arm_scmi/system.c | 42 ++- drivers/hwmon/scmi-hwmon.c | 26 +- drivers/reset/reset-scmi.c | 26 +- include/linux/scmi_protocol.h | 78 +++-- 23 files changed, 1354 insertions(+), 414 deletions(-) create mode 100644 drivers/firmware/arm_scmi/scmi_custom.c create mode 100644 drivers/firmware/arm_scmi/scmi_custom_dummy.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: f.fainelli@gmail.com, vincent.guittot@linaro.org, sudeep.holla@arm.com, thara.gopinath@linaro.org, cristian.marussi@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, souvik.chakravarty@arm.com, etienne.carriere@linaro.org, lukasz.luba@arm.com Subject: [PATCH 00/11] SCMI vendor protocols and modularization Date: Wed, 14 Oct 2020 16:05:34 +0100 [thread overview] Message-ID: <20201014150545.44807-1-cristian.marussi@arm.com> (raw) Hi all, The current SCMI implementation does not provide an interface to easily develop and include a custom vendor protocol implementation as prescribed by the SCMI standard, also because, there is not currently any custom protocol in the upstream to justify the development of a custom interface and its maintenance. Moreover the current interface exposes protocol operations to the SCMI driver users attaching per-protocol operations directly to the handle structure, which, in this way, tends to grow indefinitely for each new protocol addition. Beside this, protocols private data are also exposed via handle *_priv pointers, making such private data accessible also to the SCMI drivers even if neither really needed nor advisable. Patches 1,2,3 try to address this simplifying the SCMI protocols interface and reducing it to these common generic operations: handle->get_ops() / handle->put_ops() / handle->notify_ops() All protocols' private data pointers are removed from handle too and made accessible only to the protocols code through dedicated internal helpers. Moreover protocol initialization is moved away from device probe and now happens on demand when the first user shows up (first .get_ops), while de-initialization is performed once the last user of the protocol (even in terms of notifications) is gone, with the SCMI core taking care to perform all the needed underlying resource accounting. This way any new future standard or custom protocol implementation will expose a common unified interface which does not need to be extended endlessly: no need to maintain a custom interface only for vendor protos. SCMI drivers written on top of standard or custom protocols will use this same common interface to access any protocol operations. All existent upstream SCMI drivers are converted to this new interface in patch 3. Leveraging this new centralized and common initialization flow, patches 4,5 take care to refactor and simplify protocol-events registration and remove also *notify_priv from the handle interface making it accessible only to the notification core. Finally, patch 6 builds on top of this new interface and introduces a mechanism to define an SCMI protocol as a full blown module (possibly loadable) while leaving the core dealing with proper resource accounting. Moreover protocol initialization is further modified to receive dynamically a pointer to core scmi_xfer_ops at init time, so avoiding to have to export all those xfer symbols in order to make the core transfer methods available to an SCMI protocol dynamically loaded. Standard protocols are still kept as builtins, though. Patches 7-11 are marked [DEBUG] and not meant for for upstreaming but just to be used as an example of how to use all of the above madness to develop a custom dummy vendor protocol module and a related SCMI custom dummy driver. (with all related DT entry/devname). The series is currently based on for-next/scmi [1] on top of: commit fd7c58ee3026 ("firmware: arm_scmi: Fix locking in notifications") Any feedback welcome. Thanks, Cristian [1]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi Cristian Marussi (11): firmware: arm_scmi: review protocol registration interface firmware: arm_scmi: hide protocols' private data firmware: arm_scmi: introduce common protocol interface firmware: arm_scmi: refactor events registration firmware: arm_scmi: make notify_priv really private firmware: arm_scmi: add support for protocol modularization [DEBUG] firmware: arm_scmi: add example custom protocol [DEBUG] arm64: dts: juno: add example custom protocol support [DEBUG] firmware: arm_scmi: add example SCMI driver for custom protocol [DEBUG] firmware: arm_scmi: add custom_dummy SCMI devname [DEBUG][HACK] firmware: arm_scmi: force implemented protocol 0x99 arch/arm64/boot/dts/arm/juno-base.dtsi | 4 + drivers/clk/clk-scmi.c | 30 +- drivers/cpufreq/scmi-cpufreq.c | 28 +- drivers/firmware/Kconfig | 17 +- drivers/firmware/arm_scmi/Makefile | 5 + drivers/firmware/arm_scmi/base.c | 79 +++-- drivers/firmware/arm_scmi/bus.c | 71 +++-- drivers/firmware/arm_scmi/clock.c | 72 +++-- drivers/firmware/arm_scmi/common.h | 73 ++++- drivers/firmware/arm_scmi/driver.c | 292 +++++++++++++++++- drivers/firmware/arm_scmi/notify.c | 171 ++++++---- drivers/firmware/arm_scmi/notify.h | 30 +- drivers/firmware/arm_scmi/perf.c | 135 ++++---- drivers/firmware/arm_scmi/power.c | 85 +++-- drivers/firmware/arm_scmi/reset.c | 87 ++++-- drivers/firmware/arm_scmi/scmi_custom.c | 170 ++++++++++ drivers/firmware/arm_scmi/scmi_custom_dummy.c | 126 ++++++++ drivers/firmware/arm_scmi/scmi_pm_domain.c | 29 +- drivers/firmware/arm_scmi/sensors.c | 92 ++++-- drivers/firmware/arm_scmi/system.c | 42 ++- drivers/hwmon/scmi-hwmon.c | 26 +- drivers/reset/reset-scmi.c | 26 +- include/linux/scmi_protocol.h | 78 +++-- 23 files changed, 1354 insertions(+), 414 deletions(-) create mode 100644 drivers/firmware/arm_scmi/scmi_custom.c create mode 100644 drivers/firmware/arm_scmi/scmi_custom_dummy.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-10-14 15:06 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-14 15:05 Cristian Marussi [this message] 2020-10-14 15:05 ` [PATCH 00/11] SCMI vendor protocols and modularization Cristian Marussi 2020-10-14 15:05 ` [PATCH 01/11] firmware: arm_scmi: review protocol registration interface Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-14 19:03 ` Florian Fainelli 2020-10-14 19:03 ` Florian Fainelli 2020-10-14 20:20 ` Sudeep Holla 2020-10-14 20:20 ` Sudeep Holla 2020-10-15 8:42 ` Cristian Marussi 2020-10-15 8:42 ` Cristian Marussi 2020-10-15 9:41 ` Vincent Guittot 2020-10-15 9:41 ` Vincent Guittot 2020-10-15 9:58 ` Cristian Marussi 2020-10-15 9:58 ` Cristian Marussi 2020-10-21 2:46 ` Thara Gopinath 2020-10-21 2:46 ` Thara Gopinath 2020-10-21 10:08 ` Cristian Marussi 2020-10-21 10:08 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 02/11] firmware: arm_scmi: hide protocols' private data Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-14 19:19 ` Florian Fainelli 2020-10-14 19:19 ` Florian Fainelli 2020-10-15 8:52 ` Cristian Marussi 2020-10-15 8:52 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 03/11] firmware: arm_scmi: introduce common protocol interface Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-21 2:47 ` Thara Gopinath 2020-10-21 2:47 ` Thara Gopinath 2020-10-21 10:27 ` Cristian Marussi 2020-10-21 10:27 ` Cristian Marussi 2020-10-26 13:07 ` Thara Gopinath 2020-10-26 13:07 ` Thara Gopinath 2020-10-28 21:04 ` Cristian Marussi 2020-10-28 21:04 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 04/11] firmware: arm_scmi: refactor events registration Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 05/11] firmware: arm_scmi: make notify_priv really private Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 06/11] firmware: arm_scmi: add support for protocol modularization Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-21 2:47 ` Thara Gopinath 2020-10-21 2:47 ` Thara Gopinath 2020-10-21 10:30 ` Cristian Marussi 2020-10-21 10:30 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 07/11] [DEBUG] firmware: arm_scmi: add example custom protocol Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 08/11] [DEBUG] arm64: dts: juno: add example custom protocol support Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 09/11] [DEBUG] firmware: arm_scmi: add example SCMI driver for custom protocol Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-14 15:55 ` Randy Dunlap 2020-10-14 15:55 ` Randy Dunlap 2020-10-14 16:44 ` Cristian Marussi 2020-10-14 16:44 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 10/11] [DEBUG] firmware: arm_scmi: add custom_dummy SCMI devname Cristian Marussi 2020-10-14 15:05 ` Cristian Marussi 2020-10-21 2:49 ` Thara Gopinath 2020-10-21 2:49 ` Thara Gopinath 2020-10-21 11:35 ` Cristian Marussi 2020-10-21 11:35 ` Cristian Marussi 2020-10-26 12:37 ` Thara Gopinath 2020-10-26 12:37 ` Thara Gopinath 2020-10-28 21:28 ` Cristian Marussi 2020-10-28 21:28 ` Cristian Marussi 2020-10-14 15:05 ` [PATCH 11/11] [DEBUG][HACK] firmware: arm_scmi: force implemented protocol 0x99 Cristian Marussi 2020-10-14 15:05 ` 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=20201014150545.44807-1-cristian.marussi@arm.com \ --to=cristian.marussi@arm.com \ --cc=Jonathan.Cameron@Huawei.com \ --cc=etienne.carriere@linaro.org \ --cc=f.fainelli@gmail.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=souvik.chakravarty@arm.com \ --cc=sudeep.holla@arm.com \ --cc=thara.gopinath@linaro.org \ --cc=vincent.guittot@linaro.org \ /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.