From: Peter Hilber <peter.hilber@opensynergy.com>
To: <linux-arm-kernel@lists.infradead.org>, <devicetree@vger.kernel.org>
Cc: Igor Skalkin <igor.skalkin@opensynergy.com>,
Peter Hilber <peter.hilber@opensynergy.com>,
Rob Herring <robh+dt@kernel.org>, <linux-kernel@vger.kernel.org>,
<sudeep.holla@arm.com>, <souvik.chakravarty@arm.com>,
<alex.bennee@linaro.org>, <jean-philippe@linaro.org>,
<mikhail.golubev@opensynergy.com>,
<anton.yakovlev@opensynergy.com>
Subject: [RFC PATCH v2 05/10] firmware: arm_scmi: Add xfer_init_buffers transport op
Date: Thu, 5 Nov 2020 22:21:11 +0100 [thread overview]
Message-ID: <20201105212116.411422-6-peter.hilber@opensynergy.com> (raw)
In-Reply-To: <20201105212116.411422-1-peter.hilber@opensynergy.com>
From: Igor Skalkin <igor.skalkin@opensynergy.com>
The virtio transport in this patch series can be simplified by using the
scmi_xfer tx/rx buffers for data exchange with the virtio device, and
for saving the message state. But the virtio transport requires
prepending a transport-specific header. Also, for data exchange using
virtqueues, the tx and rx buffers should not overlap.
After the previous patch, this is the second and final step to enable
the virtio transport to use the scmi_xfer buffers for data exchange.
Add an optional op through which the transport can allocate the tx/rx
buffers along with room for the prepended transport-specific headers.
Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com>
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com>
---
drivers/firmware/arm_scmi/common.h | 3 +++
drivers/firmware/arm_scmi/driver.c | 21 +++++++++++++++------
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index c998ec29018e..ae5db602e45d 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -208,6 +208,7 @@ struct scmi_chan_info {
* @get_max_msg: Optional callback to provide max_msg dynamically
* @max_msg: Maximum number of messages for the channel type (tx or rx)
* that can be pending simultaneously in the system
+ * @xfer_init_buffers: Callback to initialize buffers for scmi_xfer
* @send_message: Callback to send a message
* @mark_txdone: Callback to mark tx as done
* @fetch_response: Callback to fetch response
@@ -222,6 +223,8 @@ struct scmi_transport_ops {
int (*chan_free)(int id, void *p, void *data);
int (*get_max_msg)(bool tx, struct scmi_chan_info *base_cinfo,
int *max_msg);
+ int (*xfer_init_buffers)(struct scmi_chan_info *cinfo,
+ struct scmi_xfer *xfer, int max_msg_size);
int (*send_message)(struct scmi_chan_info *cinfo,
struct scmi_xfer *xfer);
void (*mark_txdone)(struct scmi_chan_info *cinfo, int ret);
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index e2faa526dfce..d7ad5a77b9dc 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -640,12 +640,21 @@ static int __scmi_xfer_info_init(struct scmi_info *sinfo,
/* Pre-initialize the buffer pointer to pre-allocated buffers */
for (i = 0, xfer = info->xfer_block; i < info->max_msg; i++, xfer++) {
- xfer->rx.buf = devm_kcalloc(dev, sizeof(u8), desc->max_msg_size,
- GFP_KERNEL);
- if (!xfer->rx.buf)
- return -ENOMEM;
-
- xfer->tx.buf = xfer->rx.buf;
+ if (desc->ops->xfer_init_buffers) {
+ int ret = desc->ops->xfer_init_buffers(
+ base_cinfo, xfer, desc->max_msg_size);
+
+ if (ret)
+ return ret;
+ } else {
+ xfer->rx.buf = devm_kcalloc(dev, sizeof(u8),
+ desc->max_msg_size,
+ GFP_KERNEL);
+ if (!xfer->rx.buf)
+ return -ENOMEM;
+
+ xfer->tx.buf = xfer->rx.buf;
+ }
init_completion(&xfer->done);
}
--
2.25.1
next prev parent reply other threads:[~2020-11-05 21:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-05 21:21 [RFC PATCH v2 00/10] firmware: arm_scmi: Add virtio transport Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 01/10] firmware: arm_scmi, smccc, mailbox: Make shmem based transports optional Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 02/10] firmware: arm_scmi: Document that max_msg is a per channel type limit Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 03/10] firmware: arm_scmi: Add op to override max message # Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 04/10] firmware: arm_scmi: Add per message transport data Peter Hilber
2020-11-05 21:21 ` Peter Hilber [this message]
2020-11-05 21:21 ` [RFC PATCH v2 06/10] firmware: arm_scmi: Add optional link_supplier() transport op Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 07/10] firmware: arm_scmi: Add per-device transport private info Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 08/10] firmware: arm_scmi: Add is_scmi_protocol_device() Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 09/10] dt-bindings: arm: Add virtio transport for SCMI Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 10/10] firmware: arm_scmi: Add virtio transport Peter Hilber
2020-11-10 21:32 ` Cristian Marussi
2020-11-12 10:57 ` Peter Hilber
2020-11-17 21:20 ` Cristian Marussi
2021-04-08 3:45 ` Viresh Kumar
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=20201105212116.411422-6-peter.hilber@opensynergy.com \
--to=peter.hilber@opensynergy.com \
--cc=alex.bennee@linaro.org \
--cc=anton.yakovlev@opensynergy.com \
--cc=devicetree@vger.kernel.org \
--cc=igor.skalkin@opensynergy.com \
--cc=jean-philippe@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikhail.golubev@opensynergy.com \
--cc=robh+dt@kernel.org \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
/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