Felipe, On Fri, Nov 19, 2010 at 8:25 AM, Felipe Balbi <me@xxxxxxxxxxxxxxx> wrote: > Hi, (at home already), > > On Fri, 2010-11-19 at 07:57 -0600, Kanigeri, Hari wrote: >> > think of it as FIFO. So the first completed message is the first in your >> > list of requests. Ain't that easy ? :-) >> >> Actually it isn't that easy ;) because there is no guarantee that the >> completed message is the first one in the list of requests. >> Responses could be asynchronous and we cannot depend on serialized >> handling of requests on BIOS...even in some cases you might not even >> get a response for particular request in which case you have to handle >> that in IPC module. > > you did not get what I said then. 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. > > 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. 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. You enable TX irq only when the mbox fifo is full. > > return; > > then on IRQ handler, when the message is completed you do: > > request = list_first_entry(mbox->req_list); > list_del(request->list); > > /* unlock */ > request->complete(); > /* lock again */ > > you will always one message at a time, so you know that when you get the > IRQ, the first message on your list is what was just completed. > >> eg: Process A sends a message to M3 core to kick off some translation >> in some codec, the thread handling this request running on BIOS would >> kick off the translation and wait for the completion before sending >> the response. In the mean time BIOS will be handling other requests >> coming to it, and shouldn't be blocked until the completion of first >> request. > > why you're involving BIOS here ? mailbox should not have to know what's > on the other side. All it needs to know is how to get the message to the > other side, no matter _what_ it is. > > So until BIOS sends the response, you would not start another transfer > on mailbox neither you would any IRQ, right ? That's not true. Even if BIOS doesn't respond to a request, you could still keep sending the messages. Thank you, Best regards, Hari Kanigeri -- 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
