From: Peter Hilber <peter.hilber@opensynergy.com> To: <linux-arm-kernel@lists.infradead.org>, <devicetree@vger.kernel.org> Cc: 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>, <igor.skalkin@opensynergy.com>, <mikhail.golubev@opensynergy.com>, <anton.yakovlev@opensynergy.com>, Peter Hilber <peter.hilber@opensynergy.com> Subject: [RFC PATCH 5/7] firmware: arm_scmi: Add xfer_init_buffers transport op Date: Fri, 18 Sep 2020 18:55:30 +0200 [thread overview] Message-ID: <20200918165530.257023-1-peter.hilber@opensynergy.com> (raw) In-Reply-To: <20200918162311.254564-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 e3ccec954e93..c6071ffe4346 100644 --- a/drivers/firmware/arm_scmi/common.h +++ b/drivers/firmware/arm_scmi/common.h @@ -206,6 +206,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 @@ -220,6 +221,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 d66f19b27c44..2e25f6f068f5 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -632,12 +632,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
WARNING: multiple messages have this Message-ID (diff)
From: Peter Hilber <peter.hilber@opensynergy.com> To: <linux-arm-kernel@lists.infradead.org>, <devicetree@vger.kernel.org> Cc: jean-philippe@linaro.org, mikhail.golubev@opensynergy.com, souvik.chakravarty@arm.com, igor.skalkin@opensynergy.com, linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>, Peter Hilber <peter.hilber@opensynergy.com>, anton.yakovlev@opensynergy.com, sudeep.holla@arm.com, alex.bennee@linaro.org Subject: [RFC PATCH 5/7] firmware: arm_scmi: Add xfer_init_buffers transport op Date: Fri, 18 Sep 2020 18:55:30 +0200 [thread overview] Message-ID: <20200918165530.257023-1-peter.hilber@opensynergy.com> (raw) In-Reply-To: <20200918162311.254564-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 e3ccec954e93..c6071ffe4346 100644 --- a/drivers/firmware/arm_scmi/common.h +++ b/drivers/firmware/arm_scmi/common.h @@ -206,6 +206,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 @@ -220,6 +221,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 d66f19b27c44..2e25f6f068f5 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -632,12 +632,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 _______________________________________________ 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:[~2020-09-18 16:56 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-18 16:23 [RFC PATCH 0/7] firmware: arm_scmi: Add virtio transport Peter Hilber 2020-09-18 16:23 ` [virtio-dev] " Peter Hilber 2020-09-18 16:23 ` Peter Hilber 2020-09-18 16:46 ` [RFC PATCH 1/7] firmware: arm_scmi, smccc, mailbox: Make shmem based transports optional Peter Hilber 2020-09-18 16:46 ` Peter Hilber 2020-09-18 16:52 ` [RFC PATCH 2/7] firmware: arm_scmi: Document that max_msg is a per channel type limit Peter Hilber 2020-09-18 16:52 ` Peter Hilber 2020-09-18 16:53 ` [RFC PATCH 3/7] firmware: arm_scmi: Add op to override max message # Peter Hilber 2020-09-18 16:53 ` Peter Hilber 2020-09-18 16:54 ` [RFC PATCH 4/7] firmware: arm_scmi: Add per message transport data Peter Hilber 2020-09-18 16:54 ` Peter Hilber 2020-09-18 16:55 ` Peter Hilber [this message] 2020-09-18 16:55 ` [RFC PATCH 5/7] firmware: arm_scmi: Add xfer_init_buffers transport op Peter Hilber 2020-09-18 16:55 ` [RFC PATCH 6/7] dt-bindings: arm: Add virtio transport for SCMI Peter Hilber 2020-09-18 16:55 ` [virtio-dev] " Peter Hilber 2020-09-18 16:55 ` Peter Hilber 2020-09-23 20:54 ` Rob Herring 2020-09-23 20:54 ` Rob Herring 2020-09-23 20:54 ` Rob Herring 2020-10-02 8:18 ` Peter Hilber 2020-10-02 8:18 ` [virtio-dev] " Peter Hilber 2020-10-02 8:18 ` Peter Hilber 2020-09-18 16:56 ` [RFC PATCH 7/7] firmware: arm_scmi: Add virtio transport Peter Hilber 2020-09-18 16:56 ` [virtio-dev] " Peter Hilber 2020-09-18 16:56 ` Peter Hilber
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=20200918165530.257023-1-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: 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.