From: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: signaling txdone for synchronos mailboxes
Date: Wed, 19 Aug 2026 12:00:43 +0200 [thread overview]
Message-ID: <aoV3U0f9wAR7yxK2@monoceros> (raw)
[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]
Hello,
I'm working on porting a mailbox/remoteproc driver from a vendor tree[1]
to mainline. One thing that is unclear to me is how txdone should be
signalled on that hardware. On that platform there is no feedback on
how/when the remote side saw/processed the message and the local side is
immediately ready to send the next signal.
So both MBOX_TXDONE_BY_IRQ and MBOX_TXDONE_BY_POLL are ruled out. It's
not completely clear to me how MBOX_TXDONE_BY_ACK is supposed to work
and thus also if that is the way to go for that driver.
Who is supposed to call mbox_client_txdone()? From what I read I'd
expect that it should be called by the client once it saw some return
signal---probably using a higher level protocol? My current workaround
is that mbox_client_txdone() is called directly after
mbox_send_message(), but that feels wrong because then the client has to
know the that mailbox in use needs that function call to progress.
So a saner approach would be to call tx_tick() from the .send_data()
callback as there it's known that the controller needs it. Currently
that doesn't work directly as &chan->lock is held by msg_submit() when
.send_data() is called and tx_tick() grabs that lock, too. If that is
the right approach, we'd need a variant of tx_tick() that assumes that
the lock is already taken. Does that make sense?
Looking at the first few callers of mbox_client_txdone():
- drivers/acpi/cppc_acpi.c has:
mbox_send_message(pcc_ss_data->pcc_channel->mchan, &cmd);
...
ret = check_pcc_chan(pcc_ss_id, true);
...
if (pcc_ss_data->pcc_channel->mchan->mbox->txdone_irq)
mbox_chan_txdone(pcc_ss_data->pcc_channel->mchan, ret);
else
mbox_client_txdone(pcc_ss_data->pcc_channel->mchan, ret);
That looks like the client has to know stuff about the internals of
the mailbox, which is ugly and feels like an incomplete abstraction.
- drivers/clk/hisilicon/clk-hi3660-stub.c has:
mbox_send_message(stub_clk_chan.mbox, stub_clk->msg);
mbox_client_txdone(stub_clk_chan.mbox, 0);
and so also knows that the used mailbox has MBOX_TXDONE_BY_ACK and
instantly assumes the message to be sent.
- drivers/crypto/bcm/cipher.c is similar to drivers/acpi/cppc_acpi.c
- drivers/devfreq/hisi_uncore_freq.c looks as if it should use
MBOX_TXDONE_BY_POLL.
- drivers/dma/bcm-sba-raid.c is similar to drivers/acpi/cppc_acpi.c,
too
- drivers/firmware/arm_scmi/transports/mailbox.c seems to be a
legitimate user of mbox_client_txdone(), only calling it after some
reply was received from the other side. I wonder however how the
driver knows that the used mailbox uses MBOX_TXDONE_BY_ACK?
Any thoughts?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
reply other threads:[~2026-08-19 10:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=aoV3U0f9wAR7yxK2@monoceros \
--to=u.kleine-koenig@baylibre.com \
--cc=jassisinghbrar@gmail.com \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®