From: Beleswar Padhi <b-padhi@ti.com>
To: <nm@ti.com>, <kristo@kernel.org>, <ssantosh@kernel.org>,
<afd@ti.com>, <vigneshr@ti.com>, <u-kumar1@ti.com>
Cc: <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <b-padhi@ti.com>
Subject: [PATCH 10/22] firmware: ti_sci: Use tx_message as message buffer directly
Date: Wed, 30 Sep 2026 01:47:34 +0530 [thread overview]
Message-ID: <20260929201746.4078803-11-b-padhi@ti.com> (raw)
In-Reply-To: <20260929201746.4078803-1-b-padhi@ti.com>
From: Andrew Davis <afd@ti.com>
As we now have the tx_message during the whole xfer process we can use
that as our message buffer to be sent. This removes an extra copy.
Note: the mailbox framework keeps only a pointer to tx_message and may
submit it after ti_sci_do_xfer() returns if it was queued behind
other messages. But, this cannot happen in practice: messages expecting
a response are always submitted before their callers return, and the
only no-response message (PREPARE_SLEEP for Partial-IO) is sent from the
power-off handler with other CPUs stopped, after which nothing else uses
the TX channel.
Signed-off-by: Andrew Davis <afd@ti.com>
Co-developed-by: Beleswar Padhi <b-padhi@ti.com>
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
Note:
To avoid KASAN warnings, and possible duplicate message resend, it's
better for the following ti-msgmgr mbox patch series to be applied
before this one goes in:
https://lore.kernel.org/all/20260929200159.4033010-1-b-padhi@ti.com/
drivers/firmware/ti_sci.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index dbe192142bf17..6ed67160c6a7f 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -43,18 +43,13 @@ static DEFINE_MUTEX(ti_sci_list_mutex);
/**
* struct ti_sci_xfer - Structure representing a message flow
* @tx_message: Transmit message
- * @tx_buf: Pointer to the message to send
* @rx_buf: Pointer to store received message
* @rx_len: Receive message length
* @xfer_buf: Preallocated buffer to store receive message
- * Since we work with request-ACK protocol, we can
- * reuse the same buffer for the rx path as we
- * use for the tx path.
* @done: completion event
*/
struct ti_sci_xfer {
struct ti_msgmgr_message tx_message;
- void *tx_buf;
void *rx_buf;
u8 rx_len;
u8 *xfer_buf;
@@ -372,16 +367,16 @@ static struct ti_sci_xfer *ti_sci_get_one_xfer(struct ti_sci_info *info,
xfer = &minfo->xfer_block[xfer_id];
- hdr = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
xfer->tx_message.len = tx_message_size;
xfer->tx_message.chan_rx = info->chan_rx;
xfer->tx_message.timeout_rx_ms = info->desc->max_rx_timeout_ms;
- xfer->tx_buf = tx_message;
+ xfer->tx_message.buf = tx_message;
xfer->rx_buf = rx_message;
xfer->rx_len = (u8)rx_message_size;
reinit_completion(&xfer->done);
+ hdr = (struct ti_sci_msg_hdr *)tx_message;
hdr->seq = xfer_id;
hdr->type = msg_type;
hdr->host = info->host_id;
@@ -487,10 +482,6 @@ static inline int ti_sci_do_xfer(const struct ti_sci_handle *handle,
if (IS_ERR(xfer))
return PTR_ERR(xfer);
- memcpy(xfer->xfer_buf + sizeof(struct ti_sci_msg_hdr),
- xfer->tx_buf + sizeof(struct ti_sci_msg_hdr),
- xfer->tx_message.len - sizeof(struct ti_sci_msg_hdr));
-
ret = mbox_send_message(info->chan_tx, &xfer->tx_message);
if (ret < 0) {
dev_err(dev, "Mbox send fail %d (caller: %pS)\n", ret, caller);
@@ -3396,7 +3387,6 @@ static int ti_sci_probe(struct platform_device *pdev)
if (!xfer->xfer_buf)
return -ENOMEM;
- xfer->tx_message.buf = xfer->xfer_buf;
init_completion(&xfer->done);
}
--
2.34.1
next prev parent reply other threads:[~2026-09-29 20:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 20:17 [PATCH 00/22] Cleanup and Refactor TI-SCI driver Beleswar Padhi
2026-09-29 20:17 ` [PATCH 01/22] firmware: ti_sci: Move error message handling into ti_sci_get_one_xfer() Beleswar Padhi
2026-09-29 20:17 ` [PATCH 02/22] firmware: ti_sci: Move error message handling into ti_sci_do_xfer() Beleswar Padhi
2026-09-29 20:17 ` [PATCH 03/22] firmware: ti_sci: Move check for ACK " Beleswar Padhi
2026-09-29 20:17 ` [PATCH 04/22] firmware: ti_sci: Remove out of place RM debug messages Beleswar Padhi
2026-09-29 20:17 ` [PATCH 05/22] firmware: ti_sci: Name response variable resp for consistency Beleswar Padhi
2026-09-29 20:17 ` [PATCH 06/22] firmware: ti_sci: Handle xfer cleanup inside ti_sci_do_xfer() Beleswar Padhi
2026-09-29 20:17 ` [PATCH 07/22] firmware: ti_sci: Pass request struct into ti_sci_do_xfer() Beleswar Padhi
2026-09-29 20:17 ` [PATCH 08/22] firmware: ti_sci: Combine xfer allocation and transfer functions Beleswar Padhi
2026-09-29 20:17 ` [PATCH 09/22] firmware: ti_sci: Fetch info struct from handle inside ti_sci_do_xfer() Beleswar Padhi
2026-09-29 20:17 ` Beleswar Padhi [this message]
2026-09-29 20:17 ` [PATCH 11/22] firmware: ti_sci: Use rx_message as message receive buffer Beleswar Padhi
2026-09-29 20:17 ` [PATCH 12/22] firmware: ti_sci: Fix some kernel-doc references in structs Beleswar Padhi
2026-09-29 20:17 ` [PATCH 13/22] soc: ti: ti_sci_protocol.h: Add missing documentation for structs Beleswar Padhi
2026-09-29 20:17 ` [PATCH 14/22] firmware: ti_sci: Do not export reboot control Beleswar Padhi
2026-09-29 20:17 ` [PATCH 15/22] firmware: ti_sci: Use pmops fxn pointers in suspend/resume hooks Beleswar Padhi
2026-09-29 20:17 ` [PATCH 16/22] firmware: ti_sci: Move the huge ti_sci file into its own directory Beleswar Padhi
2026-09-29 20:17 ` [PATCH 17/22] firmware: ti: ti_sci: Add missing includes for self-contained headers Beleswar Padhi
2026-09-29 20:17 ` [PATCH 18/22] firmware: ti: ti_sci_device: Move device ops into its own file Beleswar Padhi
2026-09-29 20:17 ` [PATCH 19/22] firmware: ti: ti_sci_clock: Move clock " Beleswar Padhi
2026-09-29 20:17 ` [PATCH 20/22] firmware: ti: ti_sci_pm: Move pm " Beleswar Padhi
2026-09-29 20:17 ` [PATCH 21/22] firmware: ti: ti_sci_rm: Move rm " Beleswar Padhi
2026-09-29 20:17 ` [PATCH 22/22] firmware: ti: ti_sci_proc: Move processor " Beleswar Padhi
2026-09-30 5:38 ` [PATCH 00/22] Cleanup and Refactor TI-SCI driver Nishanth Menon
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=20260929201746.4078803-11-b-padhi@ti.com \
--to=b-padhi@ti.com \
--cc=afd@ti.com \
--cc=kristo@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=ssantosh@kernel.org \
--cc=u-kumar1@ti.com \
--cc=vigneshr@ti.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
all inboxes | Powered by JetHome®