From: Tony Lindgren <tony@atomide.com>
To: Loic PALLARDY <loic.pallardy@st.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ohad Ben-Cohen <ohad@wizery.com>,
"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>, Juan Gutierrez <jgutierrez@ti.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Felipe Contreras <felipe.contreras@nokia.com>,
Suman Anna <s-anna@ti.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
Date: Wed, 31 Oct 2012 11:24:01 -0700 [thread overview]
Message-ID: <20121031182401.GM12739@atomide.com> (raw)
In-Reply-To: <5090E515.9050407@st.com>
* Loic PALLARDY <loic.pallardy@st.com> [121031 01:48]:
>
> Hi Omar,
>
> On 10/31/2012 08:22 AM, Omar Ramirez Luna wrote:
> >
> > As part of plat-omap code cleanup, I was planning to move omap-mailbox
> > framework to a newly drivers/mailbox folder, right now this code is
> > specific to OMAP platforms, but with some clean up it could be the
> > base for a generic framework. And living under drivers/mailbox could
> > give it some exposure for interested developers to give feedback and
> > propose changes.
> >
> > In the past there was a mailbox-like driver in mach-ux500, I was
> > hoping both could live under the same folder, however the platform
> > using it, was dropped a couple of kernel releases back and with it the
> > other similar mailbox implementation.
>
> On STE side, we are working on a mailbox driver which will rely on
> mailbox framework.
> However some modifications in current Omap mailbox framework are needed
> to fit STE HW specificities.
> - API naming should be generic (replace omap prefix by mailbox)
> - message type should be enhanced
> - fifo mechanism is linked to Omap maibox, not needed in STE case since
> it relies on cross interrupt + shared memory
> I already have modifications I'll send you to see how we can create a
> common and generic mailbox framework.
OK cool. How about Omar first posts the fixed minimal patches
to move things to live under drivers so can fix up omap for
ARCH_MULTIPLATFORM?
I can then put just those into an immutable branch that people
can pull in as needed, and you guys can continue from there with
the common mailbox framework (and I can continue work on the
core omap code independently of the mailbox framwork work).
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
Date: Wed, 31 Oct 2012 11:24:01 -0700 [thread overview]
Message-ID: <20121031182401.GM12739@atomide.com> (raw)
In-Reply-To: <5090E515.9050407@st.com>
* Loic PALLARDY <loic.pallardy@st.com> [121031 01:48]:
>
> Hi Omar,
>
> On 10/31/2012 08:22 AM, Omar Ramirez Luna wrote:
> >
> > As part of plat-omap code cleanup, I was planning to move omap-mailbox
> > framework to a newly drivers/mailbox folder, right now this code is
> > specific to OMAP platforms, but with some clean up it could be the
> > base for a generic framework. And living under drivers/mailbox could
> > give it some exposure for interested developers to give feedback and
> > propose changes.
> >
> > In the past there was a mailbox-like driver in mach-ux500, I was
> > hoping both could live under the same folder, however the platform
> > using it, was dropped a couple of kernel releases back and with it the
> > other similar mailbox implementation.
>
> On STE side, we are working on a mailbox driver which will rely on
> mailbox framework.
> However some modifications in current Omap mailbox framework are needed
> to fit STE HW specificities.
> - API naming should be generic (replace omap prefix by mailbox)
> - message type should be enhanced
> - fifo mechanism is linked to Omap maibox, not needed in STE case since
> it relies on cross interrupt + shared memory
> I already have modifications I'll send you to see how we can create a
> common and generic mailbox framework.
OK cool. How about Omar first posts the fixed minimal patches
to move things to live under drivers so can fix up omap for
ARCH_MULTIPLATFORM?
I can then put just those into an immutable branch that people
can pull in as needed, and you guys can continue from there with
the common mailbox framework (and I can continue work on the
core omap code independently of the mailbox framwork work).
Regards,
Tony
next prev parent reply other threads:[~2012-10-31 18:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-29 17:06 [PATCH 0/2] ARM: OMAP: mailbox out of plat code Omar Ramirez Luna
2012-10-29 17:06 ` Omar Ramirez Luna
2012-10-29 17:06 ` [PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers Omar Ramirez Luna
2012-10-29 17:06 ` Omar Ramirez Luna
2012-10-29 17:52 ` Tony Lindgren
2012-10-29 17:52 ` Tony Lindgren
2012-10-30 12:18 ` Omar Ramirez Luna
2012-10-30 12:18 ` Omar Ramirez Luna
2012-10-30 16:24 ` Tony Lindgren
2012-10-30 16:24 ` Tony Lindgren
2012-10-30 21:02 ` Greg Kroah-Hartman
2012-10-30 21:02 ` Greg Kroah-Hartman
2012-10-30 21:02 ` Greg Kroah-Hartman
2012-10-31 7:22 ` Omar Ramirez Luna
2012-10-31 7:22 ` Omar Ramirez Luna
2012-10-31 8:45 ` Loic PALLARDY
2012-10-31 8:45 ` Loic PALLARDY
2012-10-31 18:24 ` Tony Lindgren [this message]
2012-10-31 18:24 ` Tony Lindgren
2012-10-29 17:06 ` [PATCH 2/2] mailbox: OMAP: introduce mailbox framework Omar Ramirez Luna
2012-10-29 17:06 ` Omar Ramirez Luna
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=20121031182401.GM12739@atomide.com \
--to=tony@atomide.com \
--cc=arnd@arndb.de \
--cc=devel@driverdev.osuosl.org \
--cc=felipe.contreras@nokia.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgutierrez@ti.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=loic.pallardy@st.com \
--cc=ohad@wizery.com \
--cc=omar.luna@linaro.org \
--cc=s-anna@ti.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.