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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux