Messages in this thread | | | Date | Tue, 6 Jul 2021 15:18:41 +0100 | From | Cristian Marussi <> | Subject | Re: [PATCH v5 08/15] firmware: arm_scmi: Introduce optional support for delegated xfers |
| |
On Mon, Jul 05, 2021 at 03:49:07PM +0100, Cristian Marussi wrote: > Some SCMI transports allow for more parallelism while handling SCMI > messages and as a result may have more complex inner workings than shared > memory based transports and they could need to maintain additional > transport-specific state information and data about the ongoing transfers. > Using the current SCMI core transport layer interface, additional effort > would be needed to keep such states and data in sync with the SCMI core. > > Allow an SCMI transport to optionally declare to be using delegated xfers > so that it can use a few SCMI core helper functions to query the core early > on in the RX path for any valid existing in-flight transfers matching a > specific message header or, alternatively, to transparently obtain a brand > new dedicated xfer to handle a notification message. > > In both cases the obtained xfer can be uniquely mapped to a specific xfer, > assured to be valid, through the means of the message header sequence > number acting as key. > > In this way such a transport can save its own transport specific envelope > into a private reference associated with the xfer before calling into the > core scmi_rx_callback() in the usual way. > > The scmi_rx_callback() does not need to be modified to carry additional > transport-specific ancillary data related to such message envelopes since > an unique natural association is established between the xfer and the > related message header. > > Existing transports that do not need anything of the above will continue > to work as before without any change. > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > ---
Hi,
as an afterthough (sigh...) on this patch of mine, I think that now, after all the support introduced earlier within this same series into the SCMI core (monotonic tokens and concurrency/out-of-order handling of responses), the additional complexity of this patch could NOT be needed anymore and I am actually experimenting dropping this patch as a whole and further simplifying the virtio transport rx logic, with the only caveat of having to modify scmi_rx_callback() prototype to allow for a new priv parameter to be optionally provided by the transport, thing that I avoided till now but it does not seem worth anymore.
I'll post a new V6 on 5.14-rc1 with this patch reworked once fully tested and ruled out any unexpected surprise.
Sorry for the noise.
Thanks, Cristian
| |