[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJe_ZhcEg--zSqEJVYz-pNRiEgz4DrsYFTK3WTHSsF9jE3vzTA@mail.gmail.com>
Date: Wed, 19 Feb 2014 16:23:44 +0530
From: Jassi Brar <jaswinder.singh@...aro.org>
To: Kumar Gala <galak@...eaurora.org>
Cc: Jassi Brar <jassisinghbrar@...il.com>,
lkml <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Anna, Suman" <s-anna@...com>, Tony Lindgren <tony@...mide.com>,
"Omar Ramirez Luna (omar.ramirez@...itl.com)"
<omar.ramirez@...itl.com>, Loic Pallardy <loic.pallardy@...com>,
LeyFoon Tan <lftan.linux@...il.com>,
Craig McGeachie <slapdau@...oo.com.au>,
Courtney Cavin <courtney.cavin@...ymobile.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCHv3 2/6] mailbox: Introduce a new common API
Hi Kumar,
On 19 February 2014 03:02, Kumar Gala <galak@...eaurora.org> wrote:
>
> On Feb 15, 2014, at 12:25 PM, Jassi Brar <jassisinghbrar@...il.com> wrote:
>
>> Introduce common framework for client/protocol drivers and
>> controller drivers of Inter-Processor-Communication (IPC).
>>
>> Client driver developers should have a look at
>> include/linux/mailbox_client.h to understand the part of
>> the API exposed to client drivers.
>> Similarly controller driver developers should have a look
>> at include/linux/mailbox_controller.h
>>
>> Signed-off-by: Jassi Brar <jaswinder.singh@...aro.org>
>> ---
>> drivers/mailbox/Makefile | 4 +
>> drivers/mailbox/mailbox.c | 534 +++++++++++++++++++++++++++++++++++++
>> include/linux/mailbox.h | 17 ++
>> include/linux/mailbox_client.h | 87 ++++++
>> include/linux/mailbox_controller.h | 102 +++++++
>> 5 files changed, 744 insertions(+)
>> create mode 100644 drivers/mailbox/mailbox.c
>> create mode 100644 include/linux/mailbox.h
>> create mode 100644 include/linux/mailbox_client.h
>> create mode 100644 include/linux/mailbox_controller.h
>
> What's the intent of trying to provide a unified interface here? I'm trying to understand what benefit we are going for, I get possibly wanting something to reduce duplication in drivers (help functions, library, etc). But do we really see benefit in a common interface for clients?
>
> Are we really going to mix a OMAP mailbox controller with a client developed for some other SoC vendor?
>
Yeah :) we may never a client reused on some other platform and that
is why I didn't yet bother implementing DT bindings to map random
clients onto mailboxes. Clients are going to be _very_ specific to
platforms(controller + remote f/w) and so we have the 'luxury' of
hardcoding that info(exact id of the mailbox) into client's code.
Apart from controllers and clients sharing helper functions in the
api, we'll also soon run into various platforms using the same mailbox
controller (or a slightly modified version) and having to support
completely different protocols, and hence clients. Clearly we don't
want to have pl320_highbank.c, pl320_abc.c and pl320_xyz.c for three
different platforms. So we need the common/shared code to also help a
controller driver to behave differently on different platforms
(clients could pass platform specific info to the common controller
driver).
-jassi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists