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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
