Re: [PATCH] RFC: mailbox: Fix NULL message support in mbox_send_message()

[Jassi Brar]

On Thu, Mar 12, 2026 at 3:59 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> Hi,
>
> On Tue, Mar 10, 2026 at 8:42 PM Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote:
> >
> > > > > In my case, I have a mailbox driver that's currently downstream
> > > > > (though I hope to change that). My mailbox controller has an interrupt
> > > > > for txdone, so mailbox clients _shouldn't_ call mbox_client_txdone().
> > > > > Some clients of this mailbox client want the txdone interrupt, but
> > > > > some clients of it just care about sending doorbells.
> > > > >
> > > > So imx-dsp.c like? Please let me know what is lacking in the core to
> > > > fully support that. Happy to look into it.
> > >
> > > I know that with my downstream mailbox client, if I let NULL messages
> > > queue up I end up with a queue of a dozen or so NULL messages. The
> > > downstream client is really taking advantage (AKA abusing) the core's
> > > current NULL behavior. It truly does want the "mbox_ring_doorbell"
> > > concept of just making sure the doorbell is asserted and returning
> > > immediately. If the core changes to start queuing NULL messages, we'll
> > > have to figure out some sort of workaround...
> > >
> > You said your controller has an irq raised for the doorbell sent (?).
>
> It has an interrupt for when the remote side receives the doorbell
> (when it clears the IRQ on its side).
>
For one message we may not care if the irq gets cleared on the remote
side, but for many messages the client should want to ensure the next
message is sent only after the remote has acked the last sent doorbell
(?)
Otherwise, depending upon the h/w and f/w implementation on the remote
side, a doorbell may be 'missed'. But you know your setup better, take
these as just notes.


> > If so, your clients should want to wait for that confirmation (the
> > controller driver would tick via mbox_chan_txdone).
>
> Ah, I think I see what you're saying. Functionally, I think it should
> work. Pseudocode for the client:
>
> def ring_doorbell():
>   if not previous_doorbell_acked:
>     another_doorbell_pending = true
>   else:
>     previous_doorbell_acked = false;
>     mbox_send_message(NULL)
>
> def tx_done():
>   if another_doorbell_pending:
>     another_doorbell_pending = false
>     mbox_send_message(NULL)
>   else:
>     previous_doorbell_acked = true;
>
If you get interrupt from remote, and want to respect that, then your
controller will set txdone_irq=true and call mbox_chan_txdone() Client
shouldn't call mbox_client_txdone()

> I think that will ensure the other side always gets at least one
> future interrupt when the doorbell is rung.
>
> I guess another option would be for the mailbox controller to issue
> "tx_done" immediately for NULL messages. With no data to transmit, I
> guess one could say that as soon as the interrupt is raised that the
> data is "transmitted", so maybe this would be OK too?
>
That is ok, but as I said depending on how the remote h/w and f/w is
set up, multiple back to back doorbells may 'overwrite' some. Not sure
if that will be a problem for your clients.

Cheers!
Jassi