[PATCH 3/4] mailbox: add direct synchronous send support

[Anup Patel]

On Mon, Nov 9, 2026 at 7:19 PM Jassi Brar <jassisinghbrar at gmail.com> wrote:
>
> On Thu, Oct 29, 2026 at 7:27 AM Anup Patel <anup.patel at oss.qualcomm.com> wrote:
> >
> > Hi Jassi,
> >
> > On Mon, Oct 12, 2026 at 5:52 AM Jassi Brar <jassisinghbrar at gmail.com> wrote:
> > >
> > > On Wed, Sep 30, 2026 at 10:06 AM Anup Patel <anup.patel at oss.qualcomm.com> wrote:
> > > >
> > > > From: Amirreza Zarrabi <amirreza.zarrabi at oss.qualcomm.com>
> > > >
> > > > Some mailbox controllers can complete a transaction entirely within
> > > > the calling context, without going through the queued TX state
> > > > machine or a TX-done interrupt. Add a synchronous send path so their
> > > > clients can request one and wait for the result directly.
> > > >
> > > > Controllers advertise support via the new send_data_sync() op and
> > > > clients opt in by setting tx_sync when requesting the channel.
> > > >
> > > > Channels bound this way must not call mbox_chan_txdone() or
> > > > mbox_client_txdone(), and mbox_send_message() and mbox_flush() now
> > > > reject them, since only mbox_send_message_sync() is a valid
> > > > transmit path. The client remains responsible for serializing calls
> > > > to mbox_send_message_sync() against mbox_free_channel().
> > > >
> > > Seems like you want to use mbox_client.tx_block.
> > >
> >
> > Apologies for the delayed response, the past month I was travelling
> > followed by the Linux-7.4 merge window.
> >
> > We had tried mbox_client.tx_block method in the past and we had
> > found it to be not suitable because the mbox_send_message() will
> > use wait_for_completion_timeout() which crashes when called from
> > an atomic (non-sleepable) context. Our existing mailbox clients (such
> > as system msi, clock, etc) do mailbox transfers in an atomic context.
> > Due to this reason, currently we set mbox_client.tx_block = false &
> > mbox_client.knows_txdone = true in all our mailbox client drivers.
> >
> > Using mbox_client.tx_block = false & mbox_client.knows_txdone = true
> > still does not avoid the spinlock serialization enforced by msg_submit()
> > function which works fine but adds unnecessary overhead and prevents
> > parallel message Tx from multiple CPUs to the same SBI MPXY mailbox
> > channel.
> >
> > The SBI MXPY mailbox controller driver simply sends messages to
> > higher privilege firmware upon Tx using SBI calls and when the call
> > returns the response data is returned with it. Also, there is no Tx complete
> > interrupt. The higher privilege firmware may forward this message to a
> > microcontroller over RPMI queues OR it may context-switch and forward
> > this message to a secured domain (e.g. OP-TEE) to process the message.
> > The higher privilege firmware takes care of the serialization and also allows
> > parallel SBI MPXY calls from multiple CPUs.
> >
> > The MBOX_TXDONE_BY_RETURN and send_data_sync() callback
> > allows us to avoid the Tx queuing and "chan->lock" for SBI MPXY mailbox
> > channels since this is already taken care of by the higher privilege firmware.
> >
> 1) Your clocks can't really expect to be atomic  -
> rpmi_clk_enable/disable are prepare/unprepare callbacks which can be
> called from a sleepable context anyway.
> 2) System-MSI is a good candidate which makes me notice the shmem is
> per-cpu so currently a wider-scoped channel lock is protecting it. If
> you want lock-free access to the channel you need to guard shmem
> access with local_irq_save/restore which is anyway what should have
> been doing.
>
> For the system-msi case I think the framework can be modified to
> support it better. Instead of a prolonged back-forth I have drafted
> [1] support for a new lockfree api and the semantics documentation,
> because I also know how other platforms may benefit. Please either add
> pieces from it, or even better own it, adapt it and test it before
> submitting (even replace my s.o.b if the author wants). That will be
> the least effort for all of us.

Thanks Jassi, your changes look good to me.

I will include your patches in the next revision and also ensure that
these patches work with current RPMI drivers.

Regards,
Anup