From: Cristian Marussi <cristian.marussi@arm.com> To: Florian Fainelli <f.fainelli@gmail.com> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com Subject: Re: [PATCH 4/4] firmware: arm_scmi: Introduce delegated xfers support Date: Wed, 26 May 2021 15:53:17 +0100 [thread overview] Message-ID: <20210526145317.GQ28060@e120937-lin> (raw) In-Reply-To: <659c2f2c-e236-1a70-44be-c5f6871868e7@gmail.com> On Mon, May 24, 2021 at 07:20:45PM -0700, Florian Fainelli wrote: > > > 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. I agree, definitely better to see this in the context of usage. Such virtio-scmi rework is still in progress indeed, but working in my local testing so far. The reworked V4 virtio-scmi series is still to be refined and posted, and this transitional code lives now at: https://gitlab.arm.com/linux-arm/linux-cm/-/tree/scmi_virtio_trans_V4_rework and in particular this is the patch that changes virtio-scmi transport to use the new delegated xfers. (hopefully simplfying it) https://gitlab.arm.com/linux-arm/linux-cm/-/commit/0b524f89ea6cfcf6204a5eaa8cf9030118805b2f ...but, as said, it is highly work in progress so you may just want to wait for final V4 virtio-scmi rework posted and do not bother this noise of mine :D In any case thanks a lot for the feedback so far. Cristian > -- > Florian
WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com> To: Florian Fainelli <f.fainelli@gmail.com> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com Subject: Re: [PATCH 4/4] firmware: arm_scmi: Introduce delegated xfers support Date: Wed, 26 May 2021 15:53:17 +0100 [thread overview] Message-ID: <20210526145317.GQ28060@e120937-lin> (raw) In-Reply-To: <659c2f2c-e236-1a70-44be-c5f6871868e7@gmail.com> On Mon, May 24, 2021 at 07:20:45PM -0700, Florian Fainelli wrote: > > > 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. I agree, definitely better to see this in the context of usage. Such virtio-scmi rework is still in progress indeed, but working in my local testing so far. The reworked V4 virtio-scmi series is still to be refined and posted, and this transitional code lives now at: https://gitlab.arm.com/linux-arm/linux-cm/-/tree/scmi_virtio_trans_V4_rework and in particular this is the patch that changes virtio-scmi transport to use the new delegated xfers. (hopefully simplfying it) https://gitlab.arm.com/linux-arm/linux-cm/-/commit/0b524f89ea6cfcf6204a5eaa8cf9030118805b2f ...but, as said, it is highly work in progress so you may just want to wait for final V4 virtio-scmi rework posted and do not bother this noise of mine :D In any case thanks a lot for the feedback so far. Cristian > -- > Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-26 14:53 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-24 23:14 [PATCH 0/4] Review/Extend SCMI Transport Core layer Cristian Marussi 2021-05-24 23:14 ` Cristian Marussi 2021-05-24 23:15 ` [PATCH 1/4] firmware: arm_scmi: reset_rx_to_maxsz during async commands Cristian Marussi 2021-05-24 23:15 ` Cristian Marussi 2021-05-24 23:15 ` [PATCH 2/4] firmware: arm_scmi: Add support for type handling in common functions Cristian Marussi 2021-05-24 23:15 ` Cristian Marussi 2021-05-25 1:53 ` Florian Fainelli 2021-05-25 1:53 ` Florian Fainelli 2021-05-24 23:15 ` [PATCH 3/4] firmware: arm_scmi: Introduce monotonically increasing tokens Cristian Marussi 2021-05-24 23:15 ` Cristian Marussi 2021-05-25 2:13 ` Florian Fainelli 2021-05-25 2:13 ` Florian Fainelli 2021-05-26 14:44 ` Cristian Marussi 2021-05-26 14:44 ` Cristian Marussi [not found] ` <CA+-6iNx-EoMUhOncrgYTxh52mW_7yjjBbfHK8mVyEY0Uw4piwg@mail.gmail.com> 2021-05-26 14:45 ` Cristian Marussi 2021-05-26 14:45 ` Cristian Marussi 2021-05-24 23:15 ` [PATCH 4/4] firmware: arm_scmi: Introduce delegated xfers support Cristian Marussi 2021-05-24 23:15 ` Cristian Marussi 2021-05-25 2:20 ` Florian Fainelli 2021-05-25 2:20 ` Florian Fainelli 2021-05-26 14:53 ` Cristian Marussi [this message] 2021-05-26 14:53 ` 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=20210526145317.GQ28060@e120937-lin \ --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.