Messages in this thread | | | Subject | Re: [PATCH 4/4] firmware: arm_scmi: Introduce delegated xfers support | From | Florian Fainelli <> | Date | Mon, 24 May 2021 19:20:45 -0700 |
| |
On 5/24/2021 4:15 PM, Cristian Marussi wrote: > Introduce optional support for delegated xfers allocation. > > An SCMI transport can optionally declare to support delegated xfers and > then use a few helper functions exposed by the core SCMI transport layer to > query the core for existing in-flight transfers matching a provided message > header or alternatively and transparently obtain a brand new xfer to handle > a freshly received notification message. > In both cases the obtained xfer is uniquely mapped into a specific xfer > through the means of the message header acting as key. > > In this way such a transport can properly store its own transport specific > payload into the xfer uniquely associated to the message header before > even calling into the core scmi_rx_callback() in the usual way, so that > the transport specific message envelope structures can be freed early > and there is no more need to keep track of their status till the core > fully processes the xfer to completion or times out. > > The scmi_rx_callbak() 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>
It would be better to see this in the context of its planned user, but that looked reasonable enough. -- Florian
| |