signaling txdone for synchronos mailboxes

signaling txdone for synchronos mailboxes

[Uwe Kleine-König]

[-- 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 --]