From: Cristian Marussi <cristian.marussi@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com,
Jonathan.Cameron@Huawei.com, f.fainelli@gmail.com,
etienne.carriere@linaro.org, vincent.guittot@linaro.org,
souvik.chakravarty@arm.com, cristian.marussi@arm.com
Subject: [PATCH v7 12/16] firmware: arm_scmi: Add atomic mode support to smc transport
Date: Mon, 29 Nov 2021 19:11:52 +0000 [thread overview]
Message-ID: <20211129191156.29322-13-cristian.marussi@arm.com> (raw)
In-Reply-To: <20211129191156.29322-1-cristian.marussi@arm.com>
Add a Kernel configuration option to enable SCMI SMC transport atomic
mode operation for selected SCMI transactions and leave it as default
disabled.
Substitute mutex usages with busy-waiting and declare smc transport as
.atomic_enabled if such Kernel configuration option is enabled.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v5 --> v6
- remove usage of atomic_capable
- removed needless union
- reviewed Kconfig help
v4 --> v5
- removed RFC tag
- add CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE option
- add .atomic_enable support
- make atomic_capable dependent on
CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
- make also usage of mutexes vs busy-waiting dependent on
CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
---
drivers/firmware/arm_scmi/Kconfig | 14 +++++++
drivers/firmware/arm_scmi/smc.c | 66 ++++++++++++++++++++++++++++---
2 files changed, 74 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig
index 638ecec89ff1..d429326433d1 100644
--- a/drivers/firmware/arm_scmi/Kconfig
+++ b/drivers/firmware/arm_scmi/Kconfig
@@ -78,6 +78,20 @@ config ARM_SCMI_TRANSPORT_SMC
If you want the ARM SCMI PROTOCOL stack to include support for a
transport based on SMC, answer Y.
+config ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
+ bool "Enable atomic mode support for SCMI SMC transport"
+ depends on ARM_SCMI_TRANSPORT_SMC
+ help
+ Enable support of atomic operation for SCMI SMC based transport.
+
+ If you want the SCMI SMC based transport to operate in atomic
+ mode, avoiding any kind of sleeping behaviour for selected
+ transactions on the TX path, answer Y.
+ Enabling atomic mode operations allows any SCMI driver using this
+ transport to optionally ask for atomic SCMI transactions and operate
+ in atomic context too, at the price of using a number of busy-waiting
+ primitives all over instead. If unsure say N.
+
config ARM_SCMI_TRANSPORT_VIRTIO
bool "SCMI transport based on VirtIO"
depends on VIRTIO=y || VIRTIO=ARM_SCMI_PROTOCOL
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index b2f31d3feb10..0fc49cb49185 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,9 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
+#ifdef CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
+#include <linux/processor.h>
+#endif
#include <linux/slab.h>
#include "common.h"
@@ -23,14 +27,23 @@
*
* @cinfo: SCMI channel info
* @shmem: Transmit/Receive shared memory area
- * @shmem_lock: Lock to protect access to Tx/Rx shared memory area
+ * @shmem_lock: Lock to protect access to Tx/Rx shared memory area.
+ * Used when NOT operating in atomic mode.
+ * @inflight: Atomic flag to protect access to Tx/Rx shared memory area.
+ * Used when operating in atomic mode.
* @func_id: smc/hvc call function id
*/
struct scmi_smc {
struct scmi_chan_info *cinfo;
struct scmi_shared_mem __iomem *shmem;
+#ifndef CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
+ /* Protect access to shmem area */
struct mutex shmem_lock;
+#else
+#define INFLIGHT_NONE MSG_TOKEN_MAX
+ atomic_t inflight;
+#endif
u32 func_id;
};
@@ -54,6 +67,46 @@ static bool smc_chan_available(struct device *dev, int idx)
return true;
}
+static inline void smc_channel_lock_init(struct scmi_smc *scmi_info)
+{
+#ifndef CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
+ mutex_init(&scmi_info->shmem_lock);
+#else
+ atomic_set(&scmi_info->inflight, INFLIGHT_NONE);
+#endif
+}
+
+#ifdef CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
+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;
+}
+#endif
+
+static inline void
+smc_channel_lock_acquire(struct scmi_smc *scmi_info,
+ struct scmi_xfer *xfer __maybe_unused)
+{
+#ifndef CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
+ mutex_lock(&scmi_info->shmem_lock);
+#else
+ spin_until_cond(smc_xfer_inflight(xfer, &scmi_info->inflight));
+#endif
+}
+
+static inline void smc_channel_lock_release(struct scmi_smc *scmi_info)
+{
+#ifndef CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE
+ mutex_unlock(&scmi_info->shmem_lock);
+#else
+ atomic_set(&scmi_info->inflight, INFLIGHT_NONE);
+#endif
+}
+
static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
bool tx)
{
@@ -114,7 +167,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);
+ smc_channel_lock_init(scmi_info);
cinfo->transport_info = scmi_info;
return 0;
@@ -140,10 +193,10 @@ 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);
+ smc_channel_lock_acquire(scmi_info, xfer);
shmem_tx_prepare(scmi_info->shmem, xfer);
@@ -151,7 +204,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
/* Only SMCCC_RET_NOT_SUPPORTED is valid error code */
if (res.a0) {
- mutex_unlock(&scmi_info->shmem_lock);
+ smc_channel_lock_release(scmi_info);
return -EOPNOTSUPP;
}
@@ -170,7 +223,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);
+ smc_channel_lock_release(scmi_info);
}
static const struct scmi_transport_ops scmi_smc_ops = {
@@ -196,4 +249,5 @@ const struct scmi_desc scmi_smc_desc = {
* from the shared memory area.
*/
.sync_cmds_atomic_replies = true,
+ .atomic_enabled = IS_ENABLED(CONFIG_ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE),
};
--
2.17.1
next prev parent reply other threads:[~2021-11-29 19:16 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-29 19:11 [PATCH v7 00/16] Introduce atomic support for SCMI transports Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 01/16] firmware: arm_scmi: Perform earlier cinfo lookup call in do_xfer Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 02/16] firmware: arm_scmi: Set polling timeout to max_rx_timeout_ms Cristian Marussi
2021-12-03 20:13 ` Florian Fainelli
2021-12-13 11:06 ` Sudeep Holla
2021-11-29 19:11 ` [PATCH v7 03/16] firmware: arm_scmi: Refactor message response path Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 04/16] include: trace: Add new scmi_xfer_response_wait event Cristian Marussi
2021-12-03 20:16 ` Florian Fainelli
2021-11-29 19:11 ` [PATCH v7 05/16] firmware: arm_scmi: Use new trace event scmi_xfer_response_wait Cristian Marussi
2021-12-03 20:16 ` Florian Fainelli
2021-11-29 19:11 ` [PATCH v7 06/16] firmware: arm_scmi: Add configurable polling mode for transports Cristian Marussi
2021-12-13 11:25 ` Sudeep Holla
2021-12-14 10:49 ` Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 07/16] firmware: arm_scmi: Make smc transport use common completions Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 08/16] firmware: arm_scmi: Add sync_cmds_atomic_replies transport flag Cristian Marussi
2021-12-13 11:54 ` Sudeep Holla
2021-12-14 10:52 ` Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 09/16] firmware: arm_scmi: Make smc support atomic sync commands replies Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 10/16] firmware: arm_scmi: Make optee " Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 11/16] firmware: arm_scmi: Add support for atomic transports Cristian Marussi
2021-11-29 19:11 ` Cristian Marussi [this message]
2021-12-13 11:42 ` [PATCH v7 12/16] firmware: arm_scmi: Add atomic mode support to smc transport Sudeep Holla
2021-12-14 10:54 ` Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 13/16] firmware: arm_scmi: Add new parameter to mark_txdone Cristian Marussi
2021-12-03 20:17 ` Florian Fainelli
2021-11-29 19:11 ` [PATCH v7 14/16] firmware: arm_scmi: Add atomic mode support to virtio transport Cristian Marussi
2021-12-10 12:12 ` Peter Hilber
2021-12-20 21:30 ` Cristian Marussi
2022-01-18 14:20 ` Peter Hilber
2021-12-13 11:34 ` Sudeep Holla
2021-12-14 10:56 ` Cristian Marussi
2021-11-29 19:11 ` [PATCH v7 15/16] firmware: arm_scmi: Add atomic support to clock protocol Cristian Marussi
2021-12-03 20:16 ` Florian Fainelli
2021-11-29 19:11 ` [PATCH v7 16/16] clk: scmi: Support atomic clock enable/disable API Cristian Marussi
2021-12-03 2:06 ` Stephen Boyd
2021-12-03 20:17 ` Florian Fainelli
2021-12-10 10:52 ` Vincent Guittot
2021-12-10 13:30 ` Cristian Marussi
2021-12-10 14:27 ` Vincent Guittot
2021-12-10 19:36 ` Cristian Marussi
2021-12-13 17:52 ` [PATCH v7 00/16] (subset) Introduce atomic support for SCMI transports Sudeep Holla
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=20211129191156.29322-13-cristian.marussi@arm.com \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).