mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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®