[PATCH v3 5/5] OMAP: mailbox: add notification support for multiple readers

[me@felipebalbi.com (Felipe Balbi)]

Hi Hari,

On Fri, 2010-11-19 at 08:44 -0600, Kanigeri, Hari wrote:
> Not really :). Please let me know if if I am wrong, what you
> addressing is getting the confirmation that a message is sent and what
> I am addressing with the patch is that a response is received from
> M3/DSP.

You got it wrong. My proposal addresses the same what you say, but in a
different and, IMO, better fashion. There's no need to add a blocking
notifier which you can't be sure when that'll be scheduled. Have you
measured possible worst case scenario of this patch ? What's the latency
added by the blocking notifier ? Imagine user cpu is highly busy, and it
takes a long time to call the blocking notifier, is that acceptable ?

> > Then you kick the transfers which will:
> >
> > request = list_first_entry(mbox->req_list);
> > setup_correct_registers();
> > enable_irq();
> > kick_transfer();
> 
> Writing to the mailbox fifo delivers the message to other side, and if
> the fifo is full the messages are queued up in mbox kfifo, which are
> then deliverd in the order they are received.

isn't that the same as what I suggested ? Messages are queued in the
ordered they are received and sent to BIOS at the same order.

> I don't see a use case where the senders need to know that their
> message is actually written to mbox fifo, if there is one we can look
> into it.

I never said there's such usecase :-)

> That's not true. Even if BIOS doesn't respond to a request, you could
> still keep sending the messages.

but then when do you consider a message "completed" ? When it gets sent
or when you receive a response from BIOS ?

-- 
balbi