From: Cristian Marussi <cristian.marussi@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, cristian.marussi@arm.com Subject: [PATCH v2 0/5] Review/Extend SCMI Transport Core layer Date: Tue, 1 Jun 2021 11:24:16 +0100 [thread overview] Message-ID: <20210601102421.26581-1-cristian.marussi@arm.com> (raw) Hi all, this short series is meant to review and extend a couple of SCMI transport core layer mechanisms in order to ease the interaction with more complex SCMI transport driver like the upcoming virtio-scmi and optee-scmi. The commits in this series have not and *should not* have any impact or require any change in the currently existing SCMI transports. The three main principal area of change are: - introduce monotonically increasing message tokens: change the policy used by the OSPM agent to select sequence number for outgoing messages in order to minimize the re-use of recently utilized tokens so as to mitigate the possible misbehaviors on reception of late arrival 'ghost' reply from the platform, currently hard to identify and discard. More details and ASCII art of the involved logics follows in the related commit :D - introduce optional support for delegated xfers: expose a few helpers from the SCMI core transport layer that can be used by the transports to actively query the core for existing in-flight transactions already associated with a received message header or to obtain a brand new xfer to accommodate a just received notification. The general idea is to optionally let the transports process early and more of their transport specific payloads filling the xfer already naturally associated with the received message header, so that the transport specific implementations can get rid early-on of their specific message envelope structures (before even calling into the core scmi_rx_callback()) and so avoiding upfront the need to keep track of the state of such transport specific message envelopes till the core has processed them till completion or timeout. (while not modifying the signature of scmi_rx_callback)....any feedback even on a more sensible naming for this optional feature would be highly appreciated :D - add optional support for transport-specific init/exit functions: when a transport provides .init/.exit functions in its scmi_desc descriptor, they will be called early on during SCMI core stack init/deinit, so well ahead of SCMI core probing. This allows some transports like virtio/optee to have performed early on some specific setup, such as registering as drivers also with some other kernel subsystem like virtio or optee, before the main SCMI stack is probed. This early init cannot be done through the usual kernel module_* methods because an SCMI transport implementation is not a full-fledged driver but compiled as part of the SCMI core itself, so using module_init() in a transport makes then SCMI core fail to build as a single module including the desired transports. This, as said, is intended to be preparatory work for the rework and simplification of the WIP virtio-scmi series. (init/exit support is indeed needed also by upcoming optee transport) The series is based on sudeep/for-next [1] on top of commit: commit a3b884cef873 ("firmware: arm_scmi: Add clock management to the SCMI power domain") Any feedback welcome. Thanks, Cristian --- v1 --> v2: - fixed a lot of typos in "firmware: arm_scmi: Introduce monotonically increasing tokens" - added init/exit optional support patch [1]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi Cristian Marussi (5): firmware: arm_scmi: reset_rx_to_maxsz during async commands firmware: arm_scmi: Add support for type handling in common functions firmware: arm_scmi: Add transport optional init/exit support firmware: arm_scmi: Introduce monotonically increasing tokens firmware: arm_scmi: Introduce delegated xfers support drivers/firmware/arm_scmi/common.h | 51 +++- drivers/firmware/arm_scmi/driver.c | 449 ++++++++++++++++++++++++++--- 2 files changed, 460 insertions(+), 40 deletions(-) -- 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: sudeep.holla@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, cristian.marussi@arm.com Subject: [PATCH v2 0/5] Review/Extend SCMI Transport Core layer Date: Tue, 1 Jun 2021 11:24:16 +0100 [thread overview] Message-ID: <20210601102421.26581-1-cristian.marussi@arm.com> (raw) Hi all, this short series is meant to review and extend a couple of SCMI transport core layer mechanisms in order to ease the interaction with more complex SCMI transport driver like the upcoming virtio-scmi and optee-scmi. The commits in this series have not and *should not* have any impact or require any change in the currently existing SCMI transports. The three main principal area of change are: - introduce monotonically increasing message tokens: change the policy used by the OSPM agent to select sequence number for outgoing messages in order to minimize the re-use of recently utilized tokens so as to mitigate the possible misbehaviors on reception of late arrival 'ghost' reply from the platform, currently hard to identify and discard. More details and ASCII art of the involved logics follows in the related commit :D - introduce optional support for delegated xfers: expose a few helpers from the SCMI core transport layer that can be used by the transports to actively query the core for existing in-flight transactions already associated with a received message header or to obtain a brand new xfer to accommodate a just received notification. The general idea is to optionally let the transports process early and more of their transport specific payloads filling the xfer already naturally associated with the received message header, so that the transport specific implementations can get rid early-on of their specific message envelope structures (before even calling into the core scmi_rx_callback()) and so avoiding upfront the need to keep track of the state of such transport specific message envelopes till the core has processed them till completion or timeout. (while not modifying the signature of scmi_rx_callback)....any feedback even on a more sensible naming for this optional feature would be highly appreciated :D - add optional support for transport-specific init/exit functions: when a transport provides .init/.exit functions in its scmi_desc descriptor, they will be called early on during SCMI core stack init/deinit, so well ahead of SCMI core probing. This allows some transports like virtio/optee to have performed early on some specific setup, such as registering as drivers also with some other kernel subsystem like virtio or optee, before the main SCMI stack is probed. This early init cannot be done through the usual kernel module_* methods because an SCMI transport implementation is not a full-fledged driver but compiled as part of the SCMI core itself, so using module_init() in a transport makes then SCMI core fail to build as a single module including the desired transports. This, as said, is intended to be preparatory work for the rework and simplification of the WIP virtio-scmi series. (init/exit support is indeed needed also by upcoming optee transport) The series is based on sudeep/for-next [1] on top of commit: commit a3b884cef873 ("firmware: arm_scmi: Add clock management to the SCMI power domain") Any feedback welcome. Thanks, Cristian --- v1 --> v2: - fixed a lot of typos in "firmware: arm_scmi: Introduce monotonically increasing tokens" - added init/exit optional support patch [1]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi Cristian Marussi (5): firmware: arm_scmi: reset_rx_to_maxsz during async commands firmware: arm_scmi: Add support for type handling in common functions firmware: arm_scmi: Add transport optional init/exit support firmware: arm_scmi: Introduce monotonically increasing tokens firmware: arm_scmi: Introduce delegated xfers support drivers/firmware/arm_scmi/common.h | 51 +++- drivers/firmware/arm_scmi/driver.c | 449 ++++++++++++++++++++++++++--- 2 files changed, 460 insertions(+), 40 deletions(-) -- 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-06-01 10:24 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-01 10:24 Cristian Marussi [this message] 2021-06-01 10:24 ` [PATCH v2 0/5] Review/Extend SCMI Transport Core layer Cristian Marussi 2021-06-01 10:24 ` [PATCH v2 1/5] firmware: arm_scmi: reset_rx_to_maxsz during async commands Cristian Marussi 2021-06-01 10:24 ` Cristian Marussi 2021-06-02 16:08 ` Sudeep Holla 2021-06-02 16:08 ` Sudeep Holla 2021-06-01 10:24 ` [PATCH v2 2/5] firmware: arm_scmi: Add support for type handling in common functions Cristian Marussi 2021-06-01 10:24 ` Cristian Marussi 2021-06-01 10:24 ` [PATCH v2 3/5] firmware: arm_scmi: Add transport optional init/exit support Cristian Marussi 2021-06-01 10:24 ` Cristian Marussi 2021-06-01 10:24 ` [PATCH v2 4/5] firmware: arm_scmi: Introduce monotonically increasing tokens Cristian Marussi 2021-06-01 10:24 ` Cristian Marussi 2021-06-07 17:39 ` Cristian Marussi 2021-06-07 17:39 ` Cristian Marussi 2021-06-01 10:24 ` [PATCH v2 5/5] firmware: arm_scmi: Introduce delegated xfers support Cristian Marussi 2021-06-01 10:24 ` Cristian Marussi 2021-06-04 8:54 ` (subset) [PATCH v2 0/5] Review/Extend SCMI Transport Core layer Sudeep Holla 2021-06-04 8:54 ` Sudeep Holla 2021-06-11 17:06 ` Cristian Marussi 2021-06-11 17:06 ` 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=20210601102421.26581-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=souvik.chakravarty@arm.com \ --cc=sudeep.holla@arm.com \ --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.