All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Suman Anna <s-anna@ti.com>,
	Jassi Brar <jaswinder.singh@linaro.org>,
	"Russell King - ARM Linux (linux@arm.linux.org.uk)"
	<linux@arm.linux.org.uk>,
	"Loic PALLARDY (loic.pallardy@st.com)" <loic.pallardy@st.com>,
	"Tony Lindgren (tony@atomide.com)" <tony@atomide.com>,
	"Linus Walleij (linus.walleij@linaro.org)"
	<linus.walleij@linaro.org>, Olof Johansson <olof@lixom.net>,
	"Omar Ramirez Luna (omar.ramirez@copitl.com)"
	<omar.ramirez@copitl.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [GIT PULL] mailbox driver framework for v3.10 merge window
Date: Fri, 03 May 2013 15:25:23 +0200	[thread overview]
Message-ID: <1407180.uGFidLMFHk@wuerfel> (raw)
In-Reply-To: <5182E403.1030808@ti.com>

On Thursday 02 May 2013 17:09:07 Suman Anna wrote:
> On 04/28/2013 11:07 PM, Jassi Brar wrote:
> > Now, we could either call it (effectively the TI's framework with
> > quirks for STE) as the "Common API" and then dismantle and convert it
> > patch by patch (authors and I seem to agree many things need to be
> > changed and implemented).
> >   OR we do it reasonably right the first time even if that means yet
> > another release. IMHO we should go for slow but steady thing.
> 
> I think it is your call here, either of the above approaches would
> definitely involve some rework on the framework as well as both the OMAP
> & ST mailboxes. Atleast for OMAP, the code exists in kernel but disabled
> currently due to the multi-platform support. It is pending on the move
> to drivers/mailbox folder, and can be enabled just with the first 3
> patches (and another one for renaming generic mailbox.c/.h back to
> omap_mailbox.c/.h files if we go the RFC approach) in the series
> (irrespective of the framework). TI DSP/Bridge would remain broken
> because of the omap dmtimer api dependencies on multi-platform.
> 
> I do not know how much of an impact it is for the ST driver as the
> series adds the driver, and would have to wait until the RFC is sorted
> out otherwise.

I think I'd prefer to drop the branch from the 3.10 queue then
and let you all work out a common approach for 3.11. Olof, any
other input?

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] mailbox driver framework for v3.10 merge window
Date: Fri, 03 May 2013 15:25:23 +0200	[thread overview]
Message-ID: <1407180.uGFidLMFHk@wuerfel> (raw)
In-Reply-To: <5182E403.1030808@ti.com>

On Thursday 02 May 2013 17:09:07 Suman Anna wrote:
> On 04/28/2013 11:07 PM, Jassi Brar wrote:
> > Now, we could either call it (effectively the TI's framework with
> > quirks for STE) as the "Common API" and then dismantle and convert it
> > patch by patch (authors and I seem to agree many things need to be
> > changed and implemented).
> >   OR we do it reasonably right the first time even if that means yet
> > another release. IMHO we should go for slow but steady thing.
> 
> I think it is your call here, either of the above approaches would
> definitely involve some rework on the framework as well as both the OMAP
> & ST mailboxes. Atleast for OMAP, the code exists in kernel but disabled
> currently due to the multi-platform support. It is pending on the move
> to drivers/mailbox folder, and can be enabled just with the first 3
> patches (and another one for renaming generic mailbox.c/.h back to
> omap_mailbox.c/.h files if we go the RFC approach) in the series
> (irrespective of the framework). TI DSP/Bridge would remain broken
> because of the omap dmtimer api dependencies on multi-platform.
> 
> I do not know how much of an impact it is for the ST driver as the
> series adds the driver, and would have to wait until the RFC is sorted
> out otherwise.

I think I'd prefer to drop the branch from the 3.10 queue then
and let you all work out a common approach for 3.11. Olof, any
other input?

	Arnd

  parent reply	other threads:[~2013-05-03 13:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-04 21:48 [GIT PULL] mailbox driver framework for v3.10 merge window Anna, Suman
2013-04-04 21:48 ` Anna, Suman
2013-04-09 10:55 ` Arnd Bergmann
2013-04-09 10:55   ` Arnd Bergmann
2013-04-09 15:33   ` Anna, Suman
2013-04-09 15:33     ` Anna, Suman
2013-04-29  4:07   ` Jassi Brar
2013-04-29  4:07     ` Jassi Brar
2013-05-02 22:09     ` Suman Anna
2013-05-02 22:09       ` Suman Anna
2013-05-03  2:37       ` Jassi Brar
2013-05-03  2:37         ` Jassi Brar
2013-05-03 16:29         ` Suman Anna
2013-05-03 16:29           ` Suman Anna
2013-05-03 13:25       ` Arnd Bergmann [this message]
2013-05-03 13:25         ` Arnd Bergmann
2013-05-03 13:39         ` Linus Walleij
2013-05-03 13:39           ` Linus Walleij
2013-05-03 13:49           ` Arnd Bergmann
2013-05-03 13:49             ` Arnd Bergmann
     [not found] <CAFiDJ5_++vtnrExrRoAbn89GmuKycE_tuWGjPHXTw_E0SycLpg@mail.gmail.com>
2013-06-13 15:59 ` Suman Anna
     [not found] <CAFiDJ5_1w+M6TTroeQEjOcc5GNN2RCmLN4ZB5dxQNwoc+9R1YQ@mail.gmail.com>
2013-06-16 20:14 ` Suman Anna
2013-06-17 20:01   ` Olof Johansson

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=1407180.uGFidLMFHk@wuerfel \
    --to=arnd@arndb.de \
    --cc=jaswinder.singh@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=loic.pallardy@st.com \
    --cc=olof@lixom.net \
    --cc=omar.ramirez@copitl.com \
    --cc=s-anna@ti.com \
    --cc=tony@atomide.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.