Hi all,
This series mainly aims to introduce atomic support for transports
that can support it.
At first in [2/12], as a closely related addition, it is introduced a
common way for a transport to signal to the SCMI core that it does not
offer completion interrupts, so that the usual polling behaviour based
on .poll_done() will be required: this can be done enabling statically
a global polling behaviour for the whole transport with flag
scmi_desc.force_polling OR dynamically enabling at runtime such polling
behaviour on a per-channel basis with scmi_chan_info.no_completion_irq,
typically during .chan_setup(). The usual per-command polling selection
behaviour based on hdr.poll_completion is preserved as before.
Then in [3/12], a transport that supports atomic operations on its TX path
can now declare itself as .atomic_capable and as a consequence the SCMI
core will refrain itself too from sleeping on the correspondent RX-path
even when using completion IRQs.
In [6/12] a simple method is introduced so that an SCMI driver can easily
query the core to check if the currently used transport is configured to
behave in an atomic manner: in this way, interested SCMI driver users, like
Clock framework [7/12], can optionally support atomic operations when
operating on an atomically configured transport.
In [8/12] virtio transport is declared atomic.
Finally there are 4 *tentative" RFC patch related to SMC transport.
At first [9/12] ports SMC to use the common core completions when
completion interrupt is available or otherwise revert to use common core
polling mechanism above introduced: this avoids the improper call of
scmi_rx_callback directly in smc_send_message.
Then in [10/12] SMC is converted to be .atomic_capable by substituting
the mutexes with busy-waiting to keep the channel 'locked'.
With [11/12] I introduce a flag to allow a transport to signal to the core
that upon return of a .send_message() the requested command execution can
be assumed by the core to have been fully completed by the platform, so
that the response payload (if any) can be immediately fetched without the
need to poll the channel.
Finally in [12/12] I enable the above flag for SMC transport.
As a side note on the sync_cmds_atomic_replies flag added in [11/12], note
that such flag assumes that a specific transport can set it and so
univocally assure to the SCMI core that the described behavior holds true
anytime for the said transport; in reality, in a transport like SMC such
behavior could also be dependent on the effective placement of the SCMI
platform server: while a pure EL-3 SCMI server could reasonably assure
that upon smc call termination the command is fully completed, the same
could not be true for an SCMI server living in S-EL1.
For such reasons a possible evolution could be to add also some DT property
to enable the SMC transport to conditionally enable the flag at run-time
depending on the effective runtime platform configuration in terms of
SCMI server placement.
This whole matter is up for discussion, though, maybe it's not even a real
possibility an S-EL1 SCMI server using an SMC transport, so the DT patch
has not been included in this series.
Moreover, SMC changes have NOT been tested so far (I cannot), AND they are
just a proposal at this stage to try to better abstract and unify behaviour
with the SCMI core, so they are marked as RFCs.
Atomic support has been minimally tested against the upcoming virtio
transport V7 series, while polling has been tested with mailbox transports.
The series is based on linux-next/master on top of tag next-20210824 so as
to include the recently queued series on SCMI virtio and its core changes
currently queued also on sudeep/for-next/scmi [1].
Given I'm still gathering feedback on this, I still not have CCed any
maintainer out of SCMI subsystem.
Any feedback welcome.
Thanks,
Cristian
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi
---
V3 --> V4
- rebased on linux-next/master next-20210824
- renamed .needs_polling to .no_completion_irq
- added .sync_cmds_atomic_replies
- make SMC use .sync_cmd_atomic_replies
V2 --> v3
- rebased on SCMI VirtIO V6 which in turn is based on v5.14-rc1
Cristian Marussi (12):
firmware: arm_scmi: Perform earlier cinfo lookup call in do_xfer
firmware: arm_scmi: Add configurable polling mode for transports
firmware: arm_scmi: Add support for atomic transports
include: trace: Add new scmi_xfer_response_wait event
firmware: arm_scmi: Use new trace event scmi_xfer_response_wait
firmware: arm_scmi: Add is_transport_atomic() handle method
clk: scmi: Support atomic enable/disable API
firmware: arm_scmi: Declare virtio transport .atomic_capable
[RFC] firmware: arm_scmi: Make smc transport use common completions
[RFC] firmware: arm_scmi: Make smc transport atomic
[RFC] firmware: arm_scmi: Add sync_cmds_atomic_replies transport flag
[RFC] firmware: arm_scmi: Make smc support atomic commands replies
drivers/clk/clk-scmi.c | 44 ++++--
drivers/firmware/arm_scmi/common.h | 22 +++
drivers/firmware/arm_scmi/driver.c | 224 +++++++++++++++++++++++------
drivers/firmware/arm_scmi/smc.c | 61 +++++---
drivers/firmware/arm_scmi/virtio.c | 1 +
include/linux/scmi_protocol.h | 8 ++
include/trace/events/scmi.h | 28 ++++
7 files changed, 311 insertions(+), 77 deletions(-)
--
2.17.1
When a completion irq is available use it and delegate command completion
handling to the core SCMI completion mechanism.
If no completion irq is available revert to polling, using the core common
polling machinery.
Signed-off-by: Cristian Marussi <[email protected]>
---
v3 --> v4
- renamed usage of .needs_polling to .no_completion_irq
---
drivers/firmware/arm_scmi/smc.c | 40 ++++++++++++++++-----------------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index 4effecc3bb46..adaa40df3855 100644
--- a/drivers/firmware/arm_scmi/smc.c
+++ b/drivers/firmware/arm_scmi/smc.c
@@ -25,8 +25,6 @@
* @shmem: Transmit/Receive shared memory area
* @shmem_lock: Lock to protect access to Tx/Rx shared memory area
* @func_id: smc/hvc call function id
- * @irq: Optional; employed when platforms indicates msg completion by intr.
- * @tx_complete: Optional, employed only when irq is valid.
*/
struct scmi_smc {
@@ -34,15 +32,14 @@ struct scmi_smc {
struct scmi_shared_mem __iomem *shmem;
struct mutex shmem_lock;
u32 func_id;
- int irq;
- struct completion tx_complete;
};
static irqreturn_t smc_msg_done_isr(int irq, void *data)
{
struct scmi_smc *scmi_info = data;
- complete(&scmi_info->tx_complete);
+ scmi_rx_callback(scmi_info->cinfo,
+ shmem_read_header(scmi_info->shmem), NULL);
return IRQ_HANDLED;
}
@@ -111,8 +108,8 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
dev_err(dev, "failed to setup SCMI smc irq\n");
return ret;
}
- init_completion(&scmi_info->tx_complete);
- scmi_info->irq = irq;
+ } else {
+ cinfo->no_completion_irq = true;
}
scmi_info->func_id = func_id;
@@ -142,26 +139,21 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
struct scmi_smc *scmi_info = cinfo->transport_info;
struct arm_smccc_res res;
+ /*
+ * Channel lock will be released only once response has been
+ * surely fully retrieved, so after .mark_txdone()
+ */
mutex_lock(&scmi_info->shmem_lock);
-
shmem_tx_prepare(scmi_info->shmem, xfer);
- if (scmi_info->irq)
- reinit_completion(&scmi_info->tx_complete);
-
arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
- if (scmi_info->irq)
- wait_for_completion(&scmi_info->tx_complete);
-
- scmi_rx_callback(scmi_info->cinfo,
- shmem_read_header(scmi_info->shmem), NULL);
-
- mutex_unlock(&scmi_info->shmem_lock);
-
/* Only SMCCC_RET_NOT_SUPPORTED is valid error code */
- if (res.a0)
+ if (res.a0) {
+ mutex_unlock(&scmi_info->shmem_lock);
return -EOPNOTSUPP;
+ }
+
return 0;
}
@@ -173,6 +165,13 @@ static void smc_fetch_response(struct scmi_chan_info *cinfo,
shmem_fetch_response(scmi_info->shmem, xfer);
}
+static void smc_mark_txdone(struct scmi_chan_info *cinfo, int ret)
+{
+ struct scmi_smc *scmi_info = cinfo->transport_info;
+
+ mutex_unlock(&scmi_info->shmem_lock);
+}
+
static bool
smc_poll_done(struct scmi_chan_info *cinfo, struct scmi_xfer *xfer)
{
@@ -186,6 +185,7 @@ static const struct scmi_transport_ops scmi_smc_ops = {
.chan_setup = smc_chan_setup,
.chan_free = smc_chan_free,
.send_message = smc_send_message,
+ .mark_txdone = smc_mark_txdone,
.fetch_response = smc_fetch_response,
.poll_done = smc_poll_done,
};
--
2.17.1
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.
Signed-off-by: Cristian Marussi <[email protected]>
---
drivers/firmware/arm_scmi/common.h | 8 ++++++++
drivers/firmware/arm_scmi/driver.c | 29 +++++++++++++++++------------
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 4ab310c2eae5..2ce6b38d1270 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -412,6 +412,13 @@ struct scmi_device *scmi_child_dev_find(struct device *parent,
* @max_msg_size: Maximum size of data per message that can be handled.
* @force_polling: Flag to force this whole transport to use SCMI core polling
* mechanism instead of completion interrupts even if available.
+ * @sync_cmds_atomic_replies: Flag to indicate that the transport assures
+ * synchronous-command messages are atomically
+ * completed on .send_message: no need to poll
+ * actively waiting for a response.
+ * Used by core internally only when polling is
+ * selected as a waiting for reply method: i.e.
+ * if a completion irq was found use that anyway.
* @atomic_capable: Flag to indicate that this transport is assured not to sleep
* on the TX path.
*/
@@ -423,6 +430,7 @@ struct scmi_desc {
int max_msg;
int max_msg_size;
bool force_polling;
+ bool sync_cmds_atomic_replies;
bool atomic_capable;
};
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 852baac0e614..e17285f11ce3 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -809,14 +809,24 @@ static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
(void *)_RET_IP_);
}
} else {
- /*
- * Poll on xfer using transport provided .poll_done();
- * assumes no completion interrupt was available.
- */
- ktime_t stop = ktime_add_ms(ktime_get(), timeout_ms);
+ if (!info->desc->sync_cmds_atomic_replies) {
+ /*
+ * Poll on xfer using transport provided .poll_done();
+ * assumes no completion interrupt was available.
+ */
+ ktime_t stop = ktime_add_ms(ktime_get(), timeout_ms);
+
+ spin_until_cond(scmi_xfer_done_no_timeout(cinfo,
+ xfer, stop));
+ if (ktime_after(ktime_get(), stop)) {
+ dev_err(dev,
+ "timed out in resp(caller: %pS) - polling\n",
+ (void *)_RET_IP_);
+ ret = -ETIMEDOUT;
+ }
+ }
- spin_until_cond(scmi_xfer_done_no_timeout(cinfo, xfer, stop));
- if (ktime_before(ktime_get(), stop)) {
+ if (!ret) {
unsigned long flags;
/*
@@ -829,11 +839,6 @@ static int scmi_wait_for_message_response(struct scmi_chan_info *cinfo,
xfer->state = SCMI_XFER_RESP_OK;
}
spin_unlock_irqrestore(&xfer->lock, flags);
- } else {
- dev_err(dev,
- "timed out in resp(caller: %pS) - polling\n",
- (void *)_RET_IP_);
- ret = -ETIMEDOUT;
}
}
--
2.17.1
SCMI virtio transport support does not contain any sleeping pattern, so
declare it as .atomic_capable.
Signed-off-by: Cristian Marussi <[email protected]>
---
drivers/firmware/arm_scmi/virtio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/arm_scmi/virtio.c b/drivers/firmware/arm_scmi/virtio.c
index 224577f86928..eabe430595f0 100644
--- a/drivers/firmware/arm_scmi/virtio.c
+++ b/drivers/firmware/arm_scmi/virtio.c
@@ -488,4 +488,5 @@ const struct scmi_desc scmi_virtio_desc = {
.max_rx_timeout_ms = 60000, /* for non-realtime virtio devices */
.max_msg = 0, /* overridden by virtio_get_max_msg() */
.max_msg_size = VIRTIO_SCMI_MAX_MSG_SIZE,
+ .atomic_capable = true,
};
--
2.17.1
Enable sync_cmds_atomic_replies in the SMC transport descriptor.
Signed-off-by: Cristian Marussi <[email protected]>
---
NOTE THAT this flag is probably better to be also optionally settable
using an optional DT property to address the fact that the same
transport could expose or not this feature depending on where the SCMI
server sits.
(e.g. an SCMI server in S-EL1 accessed via smc dispatcher sitting in EL3)
---
drivers/firmware/arm_scmi/smc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index c13edaace8a3..479382f3cc96 100644
--- a/drivers/firmware/arm_scmi/smc.c
+++ b/drivers/firmware/arm_scmi/smc.c
@@ -209,4 +209,5 @@ const struct scmi_desc scmi_smc_desc = {
.max_msg = 20,
.max_msg_size = 128,
.atomic_capable = true,
+ .sync_cmds_atomic_replies = true,
};
--
2.17.1
Substitute mutex usages with busy-waiting and declare smc transport as
.atomic_capable.
Signed-off-by: Cristian Marussi <[email protected]>
---
drivers/firmware/arm_scmi/smc.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index adaa40df3855..c13edaace8a3 100644
--- a/drivers/firmware/arm_scmi/smc.c
+++ b/drivers/firmware/arm_scmi/smc.c
@@ -7,6 +7,7 @@
*/
#include <linux/arm-smccc.h>
+#include <linux/atomic.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/interrupt.h>
@@ -14,6 +15,7 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/processor.h>
#include <linux/slab.h>
#include "common.h"
@@ -23,14 +25,15 @@
*
* @cinfo: SCMI channel info
* @shmem: Transmit/Receive shared memory area
- * @shmem_lock: Lock to protect access to Tx/Rx shared memory area
+ * @inflight: Atomic flag to protect access to Tx/Rx shared memory area
* @func_id: smc/hvc call function id
*/
struct scmi_smc {
struct scmi_chan_info *cinfo;
struct scmi_shared_mem __iomem *shmem;
- struct mutex shmem_lock;
+#define INFLIGHT_NONE MSG_TOKEN_MAX
+ atomic_t inflight;
u32 func_id;
};
@@ -114,7 +117,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
scmi_info->func_id = func_id;
scmi_info->cinfo = cinfo;
- mutex_init(&scmi_info->shmem_lock);
+ atomic_set(&scmi_info->inflight, INFLIGHT_NONE);
cinfo->transport_info = scmi_info;
return 0;
@@ -133,6 +136,15 @@ static int smc_chan_free(int id, void *p, void *data)
return 0;
}
+static bool smc_xfer_inflight(struct scmi_xfer *xfer, atomic_t *inflight)
+{
+ int ret;
+
+ ret = atomic_cmpxchg(inflight, INFLIGHT_NONE, xfer->hdr.seq);
+
+ return ret == INFLIGHT_NONE;
+}
+
static int smc_send_message(struct scmi_chan_info *cinfo,
struct scmi_xfer *xfer)
{
@@ -140,17 +152,18 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
struct arm_smccc_res res;
/*
- * Channel lock will be released only once response has been
+ * Channel will be released only once response has been
* surely fully retrieved, so after .mark_txdone()
*/
- mutex_lock(&scmi_info->shmem_lock);
+ spin_until_cond(smc_xfer_inflight(xfer, &scmi_info->inflight));
+
shmem_tx_prepare(scmi_info->shmem, xfer);
arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
/* Only SMCCC_RET_NOT_SUPPORTED is valid error code */
if (res.a0) {
- mutex_unlock(&scmi_info->shmem_lock);
+ atomic_set(&scmi_info->inflight, INFLIGHT_NONE);
return -EOPNOTSUPP;
}
@@ -169,7 +182,7 @@ static void smc_mark_txdone(struct scmi_chan_info *cinfo, int ret)
{
struct scmi_smc *scmi_info = cinfo->transport_info;
- mutex_unlock(&scmi_info->shmem_lock);
+ atomic_set(&scmi_info->inflight, INFLIGHT_NONE);
}
static bool
@@ -195,4 +208,5 @@ const struct scmi_desc scmi_smc_desc = {
.max_rx_timeout_ms = 30,
.max_msg = 20,
.max_msg_size = 128,
+ .atomic_capable = true,
};
--
2.17.1
On 8/24/2021 3:59 PM, Cristian Marussi wrote:
> When a completion irq is available use it and delegate command completion
> handling to the core SCMI completion mechanism.
>
> If no completion irq is available revert to polling, using the core common
> polling machinery.
>
> Signed-off-by: Cristian Marussi <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
--
Florian
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?
--
Florian
On Wed, Aug 25, 2021 at 12:38 PM Florian Fainelli <[email protected]> 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
On Wed, Aug 25, 2021 at 01:17:47PM -0400, Jim Quinlan wrote:
> On Wed, Aug 25, 2021 at 12:38 PM Florian Fainelli <[email protected]> wrote:
> >
> >
> >
Hi Florian and Jim,
> > 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.
>
The new flag .sync_cmds_atomic_replies applies only when polling mode
has been selected for a specific cmd transaction, which means when no
completion IRQ was found available OR if xfer.poll_completion was
excplicitly set for a specific command.
At the moment in this series (unknown bugs apart :D), if you have a
channel configured with a completion IRQ and the .sync_cmds_atomic_replies
set for the transport, this latter flag would be generally ignored and a
wait_for_completion() will be normally used upon reception of the
completionIRQ, UNLESS you specify that one specific command has to be
polled using the per message xfer.poll_completion flag: so you should be
already able to selectively use a polling which immediately returns after
the smc by setting xfer.poll_completion for that specific short lived
message (since sync_cmds_atomic_replies is set and applies to pollmode).
On the other side any other LONG lived message will be naturally handled
via completionIRQ + wait_for_completion. (at least that was the aim..)
!!! NOTE that you'll have also to drop
[PATCH v4 10/12] [RFC] firmware: arm_scmi: Make smc transport atomic
from this series for the wait_completion to happen as you wish.
As said I'm not sure that this whole mixing of polling and IRQs on the
same channel on a regular won't cause any issues: any feedback on this
from your setup is much appreciated.
(maybe it's fine for SMC transport, but it led to a bit of hell in the
past with mboxes AFAIK...)
Thanks a lot again for your feedback, I'll have to chat with Sudeep
about the various issues/configs possibility that we discussed and I'll
keep you in the loop.
Thanks,
Cristian
P.S.: I'll be off for a few weeks, so even though I'll keep an eye on
the mail, I cannot guarantee any responsiveness :D
On Wed, Aug 25, 2021 at 2:49 PM Cristian Marussi
<[email protected]> wrote:
>
> On Wed, Aug 25, 2021 at 01:17:47PM -0400, Jim Quinlan wrote:
> > On Wed, Aug 25, 2021 at 12:38 PM Florian Fainelli <[email protected]> wrote:
> > >
> > >
> > >
>
> Hi Florian and Jim,
>
> > > 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.
> >
>
> The new flag .sync_cmds_atomic_replies applies only when polling mode
> has been selected for a specific cmd transaction, which means when no
> completion IRQ was found available OR if xfer.poll_completion was
> excplicitly set for a specific command.
>
> At the moment in this series (unknown bugs apart :D), if you have a
> channel configured with a completion IRQ and the .sync_cmds_atomic_replies
> set for the transport, this latter flag would be generally ignored and a
> wait_for_completion() will be normally used upon reception of the
> completionIRQ, UNLESS you specify that one specific command has to be
> polled using the per message xfer.poll_completion flag: so you should be
> already able to selectively use a polling which immediately returns after
> the smc by setting xfer.poll_completion for that specific short lived
> message (since sync_cmds_atomic_replies is set and applies to pollmode).
> On the other side any other LONG lived message will be naturally handled
> via completionIRQ + wait_for_completion. (at least that was the aim..)
>
> !!! NOTE that you'll have also to drop
>
> [PATCH v4 10/12] [RFC] firmware: arm_scmi: Make smc transport atomic
>
> from this series for the wait_completion to happen as you wish.
Hi Cristian,
I've tested all commits on our SMC-based system. I also tested all commits
minus "10/12 [RFC] firmware: arm_scmi: Make smc transport atomic".
This was a basic stress test, not a comprehensive one. So
Tested-by: Jim Quinlan <[email protected]>
Of course I have a strong preference for omitting "10/12 [RFC]" :-).
FWIW, if you are not planning on dropping this commit, perhaps there
could be a transport
node in the DT, and that could contain the a bool property
"smc-atomic-capable"?
Regards,
Jim Quinlan
Broadcom STB
>
> As said I'm not sure that this whole mixing of polling and IRQs on the
> same channel on a regular won't cause any issues: any feedback on this
> from your setup is much appreciated.
> (maybe it's fine for SMC transport, but it led to a bit of hell in the
> past with mboxes AFAIK...)
>
> Thanks a lot again for your feedback, I'll have to chat with Sudeep
> about the various issues/configs possibility that we discussed and I'll
> keep you in the loop.
>
> Thanks,
> Cristian
>
> P.S.: I'll be off for a few weeks, so even though I'll keep an eye on
> the mail, I cannot guarantee any responsiveness :D
On Thu, Aug 26, 2021 at 02:29:21PM -0400, Jim Quinlan wrote:
> On Wed, Aug 25, 2021 at 2:49 PM Cristian Marussi
> <[email protected]> wrote:
> >
> > On Wed, Aug 25, 2021 at 01:17:47PM -0400, Jim Quinlan wrote:
> > > On Wed, Aug 25, 2021 at 12:38 PM Florian Fainelli <[email protected]> wrote:
> > > >
> > > >
> > > >
> >
> > Hi Florian and Jim,
> >
> > > > 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.
> > >
> >
> > The new flag .sync_cmds_atomic_replies applies only when polling mode
> > has been selected for a specific cmd transaction, which means when no
> > completion IRQ was found available OR if xfer.poll_completion was
> > excplicitly set for a specific command.
> >
> > At the moment in this series (unknown bugs apart :D), if you have a
> > channel configured with a completion IRQ and the .sync_cmds_atomic_replies
> > set for the transport, this latter flag would be generally ignored and a
> > wait_for_completion() will be normally used upon reception of the
> > completionIRQ, UNLESS you specify that one specific command has to be
> > polled using the per message xfer.poll_completion flag: so you should be
> > already able to selectively use a polling which immediately returns after
> > the smc by setting xfer.poll_completion for that specific short lived
> > message (since sync_cmds_atomic_replies is set and applies to pollmode).
> > On the other side any other LONG lived message will be naturally handled
> > via completionIRQ + wait_for_completion. (at least that was the aim..)
> >
> > !!! NOTE that you'll have also to drop
> >
> > [PATCH v4 10/12] [RFC] firmware: arm_scmi: Make smc transport atomic
> >
> > from this series for the wait_completion to happen as you wish.
>
> Hi Cristian,
>
Hi Jim,
> I've tested all commits on our SMC-based system. I also tested all commits
> minus "10/12 [RFC] firmware: arm_scmi: Make smc transport atomic".
> This was a basic stress test, not a comprehensive one. So
>
> Tested-by: Jim Quinlan <[email protected]>
>
Thanks a lot for this testing.
> Of course I have a strong preference for omitting "10/12 [RFC]" :-).
> FWIW, if you are not planning on dropping this commit, perhaps there
> could be a transport
> node in the DT, and that could contain the a bool property
> "smc-atomic-capable"?
Indeed, as I was saying more than one customer/partner is asking for this
configurability so this atomic mode should be definitely configurable.
(as it could be teh case similarly with the sync_cmds_atomic_replies
depedning on SCMI server placement..)
I'll talk with Sudeep in general about the series and this configurations;
in fact I can exclude that I'll commit this series with 10/12 as it is right
now.
Thanks for the feedback !
Cristian
>
> Regards,
> Jim Quinlan
> Broadcom STB
>
> >
> > As said I'm not sure that this whole mixing of polling and IRQs on the
> > same channel on a regular won't cause any issues: any feedback on this
> > from your setup is much appreciated.
> > (maybe it's fine for SMC transport, but it led to a bit of hell in the
> > past with mboxes AFAIK...)
> >
> > Thanks a lot again for your feedback, I'll have to chat with Sudeep
> > about the various issues/configs possibility that we discussed and I'll
> > keep you in the loop.
> >
> > Thanks,
> > Cristian
> >
> > P.S.: I'll be off for a few weeks, so even though I'll keep an eye on
> > the mail, I cannot guarantee any responsiveness :D
On Thu, Aug 26, 2021 at 02:29:21PM -0400, Jim Quinlan wrote:
> On Wed, Aug 25, 2021 at 2:49 PM Cristian Marussi
> <[email protected]> wrote:
> >
> > On Wed, Aug 25, 2021 at 01:17:47PM -0400, Jim Quinlan wrote:
> > > On Wed, Aug 25, 2021 at 12:38 PM Florian Fainelli <[email protected]> wrote:
> > > >
> > > >
> > > >
> >
> > Hi Florian and Jim,
> >
> > > > 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.
> > >
> >
> > The new flag .sync_cmds_atomic_replies applies only when polling mode
> > has been selected for a specific cmd transaction, which means when no
> > completion IRQ was found available OR if xfer.poll_completion was
> > excplicitly set for a specific command.
> >
> > At the moment in this series (unknown bugs apart :D), if you have a
> > channel configured with a completion IRQ and the .sync_cmds_atomic_replies
> > set for the transport, this latter flag would be generally ignored and a
> > wait_for_completion() will be normally used upon reception of the
> > completionIRQ, UNLESS you specify that one specific command has to be
> > polled using the per message xfer.poll_completion flag: so you should be
> > already able to selectively use a polling which immediately returns after
> > the smc by setting xfer.poll_completion for that specific short lived
> > message (since sync_cmds_atomic_replies is set and applies to pollmode).
> > On the other side any other LONG lived message will be naturally handled
> > via completionIRQ + wait_for_completion. (at least that was the aim..)
> >
> > !!! NOTE that you'll have also to drop
> >
> > [PATCH v4 10/12] [RFC] firmware: arm_scmi: Make smc transport atomic
> >
> > from this series for the wait_completion to happen as you wish.
>
> Hi Cristian,
>
Hi Jim,
> I've tested all commits on our SMC-based system. I also tested all commits
> minus "10/12 [RFC] firmware: arm_scmi: Make smc transport atomic".
> This was a basic stress test, not a comprehensive one. So
>
> Tested-by: Jim Quinlan <[email protected]>
>
> Of course I have a strong preference for omitting "10/12 [RFC]" :-).
> FWIW, if you are not planning on dropping this commit, perhaps there
> could be a transport
> node in the DT, and that could contain the a bool property
> "smc-atomic-capable"?
>
I just posted V5 on this SCMI atomic transport series, where the atomic
mode behaviour of a transport can be selected by a Kconfig which is defined
as default N: so this new series should behave out-of-the-box like with the
previous one when you had dropped as a whole the SMC atomic patch.
Any feedback welcome.
Thanks,
Cristian
On Mon, Oct 04, 2021 at 01:50:04PM -0400, Jim Quinlan wrote:
> On Thu, Sep 23, 2021 at 11:03 AM Cristian Marussi
> <[email protected]> wrote:
> >
> > On Thu, Aug 26, 2021 at 02:29:21PM -0400, Jim Quinlan wrote:
> > > On Wed, Aug 25, 2021 at 2:49 PM Cristian Marussi
> > > <[email protected]> wrote:
> > > >
> > > > On Wed, Aug 25, 2021 at 01:17:47PM -0400, Jim Quinlan wrote:
> > > > > On Wed, Aug 25, 2021 at 12:38 PM Florian Fainelli <[email protected]> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > > Hi Florian and Jim,
> > > >
> > > > > > 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.
> > > > >
> > > >
> > > > The new flag .sync_cmds_atomic_replies applies only when polling mode
> > > > has been selected for a specific cmd transaction, which means when no
> > > > completion IRQ was found available OR if xfer.poll_completion was
> > > > excplicitly set for a specific command.
> > > >
> > > > At the moment in this series (unknown bugs apart :D), if you have a
> > > > channel configured with a completion IRQ and the .sync_cmds_atomic_replies
> > > > set for the transport, this latter flag would be generally ignored and a
> > > > wait_for_completion() will be normally used upon reception of the
> > > > completionIRQ, UNLESS you specify that one specific command has to be
> > > > polled using the per message xfer.poll_completion flag: so you should be
> > > > already able to selectively use a polling which immediately returns after
> > > > the smc by setting xfer.poll_completion for that specific short lived
> > > > message (since sync_cmds_atomic_replies is set and applies to pollmode).
> > > > On the other side any other LONG lived message will be naturally handled
> > > > via completionIRQ + wait_for_completion. (at least that was the aim..)
> > > >
> > > > !!! NOTE that you'll have also to drop
> > > >
> > > > [PATCH v4 10/12] [RFC] firmware: arm_scmi: Make smc transport atomic
> > > >
> > > > from this series for the wait_completion to happen as you wish.
> > >
> > > Hi Cristian,
> > >
> >
> > Hi Jim,
> >
> > > I've tested all commits on our SMC-based system. I also tested all commits
> > > minus "10/12 [RFC] firmware: arm_scmi: Make smc transport atomic".
> > > This was a basic stress test, not a comprehensive one. So
> > >
> > > Tested-by: Jim Quinlan <[email protected]>
> > >
> > > Of course I have a strong preference for omitting "10/12 [RFC]" :-).
> > > FWIW, if you are not planning on dropping this commit, perhaps there
> > > could be a transport
> > > node in the DT, and that could contain the a bool property
> > > "smc-atomic-capable"?
> > >
> >
> > I just posted V5 on this SCMI atomic transport series, where the atomic
> > mode behaviour of a transport can be selected by a Kconfig which is defined
> > as default N: so this new series should behave out-of-the-box like with the
> > previous one when you had dropped as a whole the SMC atomic patch.
> >
> > Any feedback welcome.
>
> Hi Christian,
>
Hi Jim,
> This is very much appreciated, thanks! No feedback except
>
> Tested-by: Jim Quinlan <[email protected]>
>
Glad to hear that.
I'll see if I can gather more feedback from other partners that were
interested on using the atomic path (which was supposed to be the main
feature of this series at the end :D...)
Thanks for your testing.
Cristian
> Thanks again,
> Jim
> >
> >
> > Thanks,
> > Cristian
> >
On Thu, Sep 23, 2021 at 11:03 AM Cristian Marussi
<[email protected]> wrote:
>
> On Thu, Aug 26, 2021 at 02:29:21PM -0400, Jim Quinlan wrote:
> > On Wed, Aug 25, 2021 at 2:49 PM Cristian Marussi
> > <[email protected]> wrote:
> > >
> > > On Wed, Aug 25, 2021 at 01:17:47PM -0400, Jim Quinlan wrote:
> > > > On Wed, Aug 25, 2021 at 12:38 PM Florian Fainelli <[email protected]> wrote:
> > > > >
> > > > >
> > > > >
> > >
> > > Hi Florian and Jim,
> > >
> > > > > 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.
> > > >
> > >
> > > The new flag .sync_cmds_atomic_replies applies only when polling mode
> > > has been selected for a specific cmd transaction, which means when no
> > > completion IRQ was found available OR if xfer.poll_completion was
> > > excplicitly set for a specific command.
> > >
> > > At the moment in this series (unknown bugs apart :D), if you have a
> > > channel configured with a completion IRQ and the .sync_cmds_atomic_replies
> > > set for the transport, this latter flag would be generally ignored and a
> > > wait_for_completion() will be normally used upon reception of the
> > > completionIRQ, UNLESS you specify that one specific command has to be
> > > polled using the per message xfer.poll_completion flag: so you should be
> > > already able to selectively use a polling which immediately returns after
> > > the smc by setting xfer.poll_completion for that specific short lived
> > > message (since sync_cmds_atomic_replies is set and applies to pollmode).
> > > On the other side any other LONG lived message will be naturally handled
> > > via completionIRQ + wait_for_completion. (at least that was the aim..)
> > >
> > > !!! NOTE that you'll have also to drop
> > >
> > > [PATCH v4 10/12] [RFC] firmware: arm_scmi: Make smc transport atomic
> > >
> > > from this series for the wait_completion to happen as you wish.
> >
> > Hi Cristian,
> >
>
> Hi Jim,
>
> > I've tested all commits on our SMC-based system. I also tested all commits
> > minus "10/12 [RFC] firmware: arm_scmi: Make smc transport atomic".
> > This was a basic stress test, not a comprehensive one. So
> >
> > Tested-by: Jim Quinlan <[email protected]>
> >
> > Of course I have a strong preference for omitting "10/12 [RFC]" :-).
> > FWIW, if you are not planning on dropping this commit, perhaps there
> > could be a transport
> > node in the DT, and that could contain the a bool property
> > "smc-atomic-capable"?
> >
>
> I just posted V5 on this SCMI atomic transport series, where the atomic
> mode behaviour of a transport can be selected by a Kconfig which is defined
> as default N: so this new series should behave out-of-the-box like with the
> previous one when you had dropped as a whole the SMC atomic patch.
>
> Any feedback welcome.
Hi Christian,
This is very much appreciated, thanks! No feedback except
Tested-by: Jim Quinlan <[email protected]>
Thanks again,
Jim
>
>
> Thanks,
> Cristian
>