From: me@felipebalbi.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 5/5] OMAP: mailbox: add notification support for multiple readers
Date: Fri, 19 Nov 2010 16:25:36 +0200 [thread overview]
Message-ID: <1290176736.15533.17.camel@eowin> (raw)
In-Reply-To: <AANLkTi=VoUixouRAz-a+y9Jf6z94OtLe9UzWjnod743s@mail.gmail.com>
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.
users will queue a request, which is simply a list_add_tail() to the
mailbox's request list.
Then you kick the transfers which will:
request = list_first_entry(mbox->req_list);
setup_correct_registers();
enable_irq();
kick_transfer();
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 ?
> > Still it doesn't the fact that currently you allow for that. There are
> > malware writers everywhere. But hey, it would be cool to have mailbox
> > appear on securityfocus.com :-p
> >
>
> Agree about malware writers. Add PM interfaces as well to the list as
> one can misuse them as well ;)
for PM interfaces it's a bit more difficult and you cannot tamper with
another device's PM (well, after all are converted to hwmod, that is)
and on top of that, the biggest trouble you will run into, is your
battery dying quickly. With mailbox you have actual useful data coming
back and forth, no ?
--
balbi
next prev parent reply other threads:[~2010-11-19 14:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 19:15 [PATCH v3 0/5] OMAP: mailbox: enhancements and fixes Hari Kanigeri
2010-11-18 19:15 ` [PATCH v3 1/5] OMAP: mailbox: change full flag per mailbox queue instead of global Hari Kanigeri
2010-11-18 23:22 ` Cousson, Benoit
2010-11-18 19:15 ` [PATCH v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4 Hari Kanigeri
2010-11-18 23:28 ` Cousson, Benoit
2010-11-19 0:07 ` Kanigeri, Hari
2010-11-19 8:32 ` Felipe Balbi
2010-11-19 14:22 ` Kanigeri, Hari
2010-11-19 14:50 ` Cousson, Benoit
2010-11-22 10:08 ` Felipe Balbi
2010-11-22 11:46 ` Kanigeri, Hari
2010-11-22 11:51 ` Felipe Balbi
2010-11-22 11:58 ` Kanigeri, Hari
2010-11-22 14:57 ` Cousson, Benoit
2010-11-22 14:55 ` Cousson, Benoit
2010-11-23 8:10 ` Felipe Balbi
2010-11-19 8:32 ` Felipe Balbi
2010-11-18 19:15 ` [PATCH v3 3/5] OMAP: mailbox: fix checkpatch warnings Hari Kanigeri
2010-11-19 8:33 ` Felipe Balbi
2010-11-19 11:52 ` Kanigeri, Hari
2010-11-18 19:15 ` [PATCH v3 4/5] OMAP: mailbox: send message in process context Hari Kanigeri
2010-11-19 8:34 ` Felipe Balbi
2010-11-18 19:15 ` [PATCH v3 5/5] OMAP: mailbox: add notification support for multiple readers Hari Kanigeri
2010-11-19 8:50 ` Felipe Balbi
2010-11-19 11:50 ` Kanigeri, Hari
2010-11-19 12:09 ` Felipe Balbi
2010-11-19 12:29 ` Kanigeri, Hari
2010-11-19 12:53 ` Felipe Balbi
2010-11-19 13:57 ` Kanigeri, Hari
2010-11-19 14:25 ` Felipe Balbi [this message]
2010-11-19 14:44 ` Kanigeri, Hari
2010-11-19 23:07 ` Felipe Balbi
2010-11-20 4:01 ` Kanigeri, Hari
2010-11-20 11:31 ` Felipe Balbi
2010-11-20 13:26 ` Kanigeri, Hari
-- strict thread matches above, loose matches on Subject: below --
2010-11-21 20:03 Jacek Burghardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1290176736.15533.17.camel@eowin \
--to=me@felipebalbi.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).