On Fri, Feb 14, 2020 at 9:48 PM Samuel Holland <samuel@xxxxxxxxxxxx> wrote:
>
> On 2/12/20 8:18 PM, Samuel Holland wrote:
> > Jassi,
> >
> > On 2/12/20 8:02 PM, Jassi Brar wrote:
> >> On Sun, Jan 12, 2020 at 11:18 PM Samuel Holland <samuel@xxxxxxxxxxxx> wrote:
> >>>
> >>> +static int sun6i_msgbox_send_data(struct mbox_chan *chan, void *data)
> >>> +{
> >>> + struct sun6i_msgbox *mbox = to_sun6i_msgbox(chan);
> >>> + int n = channel_number(chan);
> >>> + uint32_t msg = *(uint32_t *)data;
> >>> +
> >>> + /* Using a channel backwards gets the hardware into a bad state. */
> >>> + if (WARN_ON_ONCE(!(readl(mbox->regs + CTRL_REG(n)) & CTRL_TX(n))))
> >>> + return 0;
> >>> +
> >>> + /* We cannot post a new message if the FIFO is full. */
> >>> + if (readl(mbox->regs + FIFO_STAT_REG(n)) & FIFO_STAT_MASK) {
> >>> + mbox_dbg(mbox, "Channel %d busy sending 0x%08x\n", n, msg);
> >>> + return -EBUSY;
> >>> + }
> >>> +
> >> This check should go into sun6i_msgbox_last_tx_done().
> >> send_data() assumes all is clear to send next packet.
> >
> > sun6i_msgbox_last_tx_done() already checks that the FIFO is completely empty (as
> > the big comment explains). So this error could only be hit in the knows_txdone
> > == true case, if the client pipelines multiple messages by calling
> > mbox_client_txdone() before the message is actually removed from the FIFO.
> >
> > From the comments in mailbox_controller.h, this kind of usage looks to be
> > unsupported. In that case, I could remove the check entirely. Does that sound right?
>
> After more thought, I would prefer to keep the check. It is fast/simple, and it
> keeps the hardware from getting into an inconsistent state. Silently dropping
> messages sounds like a poor quality of implementation.
>
If the FIFO becomes full after calling send_data(), then
last_tx_done() should not only check remote's irq status but also
check that the data has been consumed from the FIFO locally (hence the
check becomes redundant in send_data). Otherwise the last_tx_done is
incomplete. And you actually end up writing more code (error handling
and resubmission instead of the api managing it all transparently)
> send_data() is documented in mailbox_controller.h as returning EBUSY,
>
error is usually returned for s/w check (like mssg too big for fifo),
not h/w events.
> and I see multiple other mailbox controllers implementing the same or a similar check.
>
That it encourages next developer to repeat, is another reason to do
it right this time. Otherwise, I can live with that check in
send_data.
> If
> that is not the way you intend for the API to work, then please update the
> comments in mailbox_controller.h.
>
Mailbox implementations follow no spec. There may be prudent need to
return from send_data, but practically I haven't come across any(?)
platform that can't do without the check in send_data.
Cheers!
