All of lore.kernel.org
 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 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.