From: andy.green@linaro.org (Andy Green)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
Date: Wed, 24 Apr 2013 07:30:02 +0800 [thread overview]
Message-ID: <5177197A.4050104@linaro.org> (raw)
In-Reply-To: <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
On 24/04/13 03:20, the mail apparently from Anna, Suman included:
Hi Suman -
> This series missed the 3.9 merge window, and is currently slated for
> getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't
> aware of it until I saw it in mainline) and created the
> drivers/mailbox folder. I would think it would be relatively
> straight-forward to adopt it to the mailbox API, as it has only 3
> API. We should be doing incremental changes on top of this series, as
> most of the base API would still be the same. The current series is
> helping out with couple of efforts, the breaking up of the PRCMU code
> and on the multiplatform support for OMAP with mailbox enabled. We
> can definitely collaborate on the improvements. Andy Green would also
> be interested, as he is also looking into adopting the mailbox API.
To clarify Jassi works on my team, after I wrote two Mailbox drivers for
two different IP on the chips we're working on, I handed them off to him
and Jassi's working on further integration using those drivers. So
we're both doing the same thing.
From my POV I am very happy you made the new API - before that there
was only PL320 sitting there and nothing you could call an API. Once I
understood the approach (no docs was a bit painful) I was able to
implement both drivers we needed with what you have.
The main problem I have with it we discussed in direct mail previously,
since we have two different mailbox IP, we need to improve the register
/ unregister so it can cope, right now it's unnecessarily limited to one
mailbox driver.
That "there can only be one" approach also leaked out into the drivers
having filescope statics for things that should have been instantiated
per-mailbox device (including device naming as literals, rather than
mbox%d needed if there can be multiple drivers). In my driver
implementations I moved them to live in the per-device priv struct and
stored the names in there too.
The other point I mentioned before was the FIFO, it's always there and
size set by CONFIG_ stuff. Actually it would be better if it was set
per mailbox or per mailbox driver at runtime. For one of the IPs, we
will have another driver mediating access to the mailbox that enforces a
single client access covering possibly multiple mailbox messages. Under
those conditions, a fifo isn't really meaningful. But that's less of a
problem.
As I say I was very happy to see you addressing the lack of an API,
Jassi though is working deeper with it than just making the mailbox
drivers as I did; he's using the API from other consumer drivers so he
may have a different set of concerns or, looking at what he's written
here, opportunities.
-Andy
--
Andy Green | Fujitsu Landing Team Leader
Linaro.org ? Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
next prev parent reply other threads:[~2013-04-23 23:30 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 3:23 [PATCHv3 00/14] drivers: mailbox: framework creation Suman Anna
2013-03-21 11:39 ` Linus Walleij
2013-03-21 23:22 ` Stephen Rothwell
2013-03-21 23:37 ` Anna, Suman
2013-04-21 2:40 ` Jassi Brar
2013-04-22 15:56 ` Anna, Suman
2013-04-23 4:51 ` Jassi Brar
2013-04-23 19:20 ` Anna, Suman
2013-04-23 23:30 ` Andy Green [this message]
2013-04-24 4:39 ` Jassi Brar
2013-04-24 8:08 ` Loic PALLARDY
2013-04-24 8:56 ` Jassi Brar
2013-04-24 23:16 ` Suman Anna
2013-04-25 5:20 ` Jassi Brar
2013-04-25 22:29 ` Suman Anna
2013-04-25 23:51 ` Andy Green
2013-04-26 3:46 ` Jassi Brar
2013-04-27 1:04 ` Suman Anna
2013-04-27 1:48 ` Andy Green
2013-04-29 15:32 ` Suman Anna
2013-04-27 4:51 ` Jassi Brar
2013-04-27 18:05 ` [PATCH 1/3] mailbox: rename pl320-ipc specific mailbox.h jaswinder.singh at linaro.org
2013-04-29 12:46 ` Mark Langsdorf
2013-04-29 16:00 ` [PATCHv3 00/14] drivers: mailbox: framework creation Suman Anna
2013-04-29 16:49 ` Jassi Brar
[not found] ` <1367086496-28647-1-git-send-email-jaswinder.singh@linaro.org>
2013-04-29 16:44 ` [RFC 3/3] mailbox: pl320: Introduce common API driver Suman Anna
2013-04-29 16:57 ` Jassi Brar
2013-04-29 17:06 ` Mark Langsdorf
2013-04-29 17:28 ` Jassi Brar
[not found] ` <1367086474-28614-1-git-send-email-jaswinder.singh@linaro.org>
2013-05-04 2:20 ` [RFC 2/3] mailbox: Introduce a new common API Suman Anna
2013-05-04 19:08 ` Jassi Brar
2013-05-06 23:45 ` Suman Anna
2013-05-07 7:40 ` Jassi Brar
2013-05-07 21:48 ` Suman Anna
2013-05-08 5:44 ` Jassi Brar
2013-05-09 1:25 ` Suman Anna
2013-05-09 16:35 ` Jassi Brar
2013-05-10 0:18 ` Suman Anna
2013-05-10 10:06 ` Jassi Brar
2013-05-10 16:41 ` Suman Anna
2013-04-24 7:39 ` [PATCHv3 00/14] drivers: mailbox: framework creation Loic PALLARDY
2013-04-24 7:59 ` Jassi Brar
2013-04-24 8:39 ` Loic PALLARDY
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=5177197A.4050104@linaro.org \
--to=andy.green@linaro.org \
--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).