Messages in this thread | | | From | Jim Quinlan <> | Date | Wed, 25 Aug 2021 13:17:47 -0400 | Subject | Re: [PATCH v4 11/12] [RFC] firmware: arm_scmi: Add sync_cmds_atomic_replies transport flag |
| |
On Wed, Aug 25, 2021 at 12:38 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > > > On 8/24/2021 3:59 PM, Cristian Marussi wrote: > > A flag is added to let the transport signal the core that its handling of > > synchronous command messages implies that, after .send_message has returned > > successfully, the requested command can be assumed to be fully and > > completely executed on SCMI platform side so that any possible response > > value is already immediately available to be retrieved by a .fetch_reponse: > > in other words the polling phase can be skipped in such a case and the > > response values accessed straight away. > > > > Note that all of the above applies only when polling mode of operation was > > selected by the core: if instead a completion IRQ was found to be available > > the normal response processing path based on completions will still be > > followed. > > This might actually have to be settable on a per-message basis ideally > since we may be transporting short lived SCMI messages for which the > completion can be done at SMC time, and long lived SCMI messages (e.g.: > involving a voltage change) for which we would prefer a completion > interrupt. Jim, what do you think? Even if the SCMI main driver could be configured this way in an elegant manner, I'm not sure that there is a clean way of specifying this attribute on a per-message basis. Certainly we could do this with our own protocols, but many of our "long lived" messages are the Perf protocol's set_level command. At any rate, let me give it some thought.
Regards, Jim > -- > Florian [unhandled content-type:application/pkcs7-signature] | |