public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Olof Johansson <olof@lixom.net>,
	linux-arm-kernel@lists.infradead.org, linux-next@vger.kernel.org,
	linux-kernel@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
	Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Subject: Re: linux-next: manual merge of the arm-soc tree with the omap_dss2 tree
Date: Fri, 09 Mar 2012 14:14:29 +0200	[thread overview]
Message-ID: <1331295269.1927.54.camel@deskari> (raw)
In-Reply-To: <201203091150.11294.arnd@arndb.de>

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

On Fri, 2012-03-09 at 11:50 +0000, Arnd Bergmann wrote:
> On Friday 09 March 2012, Tomi Valkeinen wrote:
> > On Thu, 2012-03-08 at 16:16 +0000, Arnd Bergmann wrote:
> > > On Thursday 08 March 2012, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > > arch/arm/mach-omap1/board-palmtt.c between commit ddba6c7f7ec6 ("OMAP1:
> > > > pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
> > > > and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
> > > > iomap.h") from the arm-soc tree.
> > > > 
> > > > I fixed it up (see below) and can carry the fix as necessary.
> > > 
> > > Hi Stephen,
> > > 
> > > Thanks for fixing up all the conflicts between arm-soc and omap_dss2.
> > > I think we should make sure they are resolved in one of the trees before
> > > the merge window.
> > 
> > Do we need to? The conflicts seemed to be trivial ones, like arm-soc
> > adds/removes something that just happens to be next to something else
> > that I add/remove.
> > 
> > My understanding is that it's better to leave those conflicts than to do
> > "trickery" to avoid them.
> 
> Each of the conflicts is simple enough, but I feel it's worth resolving
> them in this case because there are a number of them. Looking at them
> again now, it's probably ok either way -- resolving them now or letting
> Linus take care of them.

Florian, do you have an opinion about this?

Merging omapdss tree through arm-soc would make sense for avoiding
conflicts, because almost every merge window there are some conflicts as
I often need to edit arch/arm files also. But I'm not sure if we have
ever had a conflict in drivers/video.

But still, it's a video driver, and fbdev tree sounds more suited for a
video driver.

So I don't know =). Basically it's ok for me either way also. But it
would be nice to have a standard way of doing this, instead of, for
example, merging omapdss sometimes through fbdev, sometimes through
arm-soc, depending on the conflicts...

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-03-09 12:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-08  6:00 linux-next: manual merge of the arm-soc tree with the omap_dss2 tree Stephen Rothwell
2012-03-08 16:16 ` Arnd Bergmann
2012-03-09  9:35   ` Tomi Valkeinen
2012-03-09 11:50     ` Arnd Bergmann
2012-03-09 12:14       ` Tomi Valkeinen [this message]
2012-03-09 12:26         ` Arnd Bergmann
2012-03-09 12:31           ` Tomi Valkeinen
  -- strict thread matches above, loose matches on Subject: below --
2013-04-09  7:40 Stephen Rothwell
2013-04-09  9:32 ` Arnd Bergmann
2012-12-03  5:52 Stephen Rothwell
2012-11-30  5:18 Stephen Rothwell
2012-11-26 10:56 Stephen Rothwell
2012-11-26 15:53 ` Tony Lindgren
2012-09-24  9:53 Stephen Rothwell
2012-09-24 12:43 ` Arnd Bergmann
2012-09-24 13:11   ` Tomi Valkeinen
2012-09-24 16:19     ` Tony Lindgren
2012-09-17  9:23 Stephen Rothwell
2012-05-14  8:51 Stephen Rothwell
2012-03-13  8:21 Stephen Rothwell
2012-03-09  7:09 Stephen Rothwell
2012-03-08  5:58 Stephen Rothwell
2012-03-08  5:55 Stephen Rothwell
2012-03-08  5:51 Stephen Rothwell
2012-03-10  9:55 ` Janusz Krzysztofik

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=1331295269.1927.54.camel@deskari \
    --to=tomi.valkeinen@ti.com \
    --cc=FlorianSchandinat@gmx.de \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=sfr@canb.auug.org.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox