All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL 5/5] minimal omap5 support for v3.6 merge window
Date: Tue, 10 Jul 2012 23:04:39 -0700	[thread overview]
Message-ID: <20120711060439.GZ1122@atomide.com> (raw)
In-Reply-To: <201207101553.01188.arnd@arndb.de>

* Arnd Bergmann <arnd@arndb.de> [120710 08:57]:
> On Tuesday 10 July 2012, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [120710 06:21]:
> > > The following changes since commit fb584511c4664573097ece7df0de06ad00b713a2:
> > > 
> > >   ARM: OMAP: sdrc: Fix the build break for OMAP4 only builds (2012-07-09 01:44:11 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap devel-omap5
> > 
> > FYI, I got some merge conflicts with the am33xx and PM/smartreflex
> > changes, here's how I resolved them.
> > 
> 
> Pulled all five branches now.

OK thanks.
 
> I put the am33xx clk data into the next/clk branch, as that seemed convenient.
> The omap5 branch is in the next/newsoc branch, together with the new Marvell
> ArmadaXP port.

OK
 
> I'm not extremely happy with the multi-level dependencies, but it's still
> manageable at the moment, especially since I have a relatively large number
> of next/* branches.

Yes me neither, that causes a lot of extra work keeping thing working.

The clean-up we did caused quite a bit of these dependencies, but
was necessary for adding am33xx and omap5 in somewhat clean way to avoid
patching all over the place to add more soc_is_omapxxxx() calls. So this
amount of dependencies should be rare.

All the clean-up should really have been in the first clean-up branch, but
was not quite ready yet at that point. That would have simplified things
a lot.
 
> If others submit pull requests that create additional dependencies I might
> have to reject them if that gets too complex.

Yes sorry about that, I too was considering leaving some of these branches
for v3.7 to let the dependencies clear out.. Anyways thanks again for the
extra effort on your part too.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL 5/5] minimal omap5 support for v3.6 merge window
Date: Tue, 10 Jul 2012 23:04:39 -0700	[thread overview]
Message-ID: <20120711060439.GZ1122@atomide.com> (raw)
In-Reply-To: <201207101553.01188.arnd@arndb.de>

* Arnd Bergmann <arnd@arndb.de> [120710 08:57]:
> On Tuesday 10 July 2012, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [120710 06:21]:
> > > The following changes since commit fb584511c4664573097ece7df0de06ad00b713a2:
> > > 
> > >   ARM: OMAP: sdrc: Fix the build break for OMAP4 only builds (2012-07-09 01:44:11 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap devel-omap5
> > 
> > FYI, I got some merge conflicts with the am33xx and PM/smartreflex
> > changes, here's how I resolved them.
> > 
> 
> Pulled all five branches now.

OK thanks.
 
> I put the am33xx clk data into the next/clk branch, as that seemed convenient.
> The omap5 branch is in the next/newsoc branch, together with the new Marvell
> ArmadaXP port.

OK
 
> I'm not extremely happy with the multi-level dependencies, but it's still
> manageable at the moment, especially since I have a relatively large number
> of next/* branches.

Yes me neither, that causes a lot of extra work keeping thing working.

The clean-up we did caused quite a bit of these dependencies, but
was necessary for adding am33xx and omap5 in somewhat clean way to avoid
patching all over the place to add more soc_is_omapxxxx() calls. So this
amount of dependencies should be rare.

All the clean-up should really have been in the first clean-up branch, but
was not quite ready yet at that point. That would have simplified things
a lot.
 
> If others submit pull requests that create additional dependencies I might
> have to reject them if that gets too complex.

Yes sorry about that, I too was considering leaving some of these branches
for v3.7 to let the dependencies clear out.. Anyways thanks again for the
extra effort on your part too.

Regards,

Tony

  reply	other threads:[~2012-07-11  6:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-10 13:05 [GIT PULL 1/5] omap device tree changes for v3.6 merge window Tony Lindgren
2012-07-10 13:05 ` [GIT PULL 2/5] omap board " Tony Lindgren
2012-07-10 13:05 ` Tony Lindgren
2012-07-10 13:05 ` [GIT PULL 3/5] omap cleanup part2 " Tony Lindgren
2012-07-10 13:05 ` [GIT PULL 5/5] minimal omap5 support " Tony Lindgren
2012-07-10 13:05 ` Tony Lindgren
2012-07-10 13:05 ` [GIT PULL 3/5] omap cleanup part2 " Tony Lindgren
2012-07-10 13:05 ` [GIT PULL 4/5] am33xx data " Tony Lindgren
2012-07-10 13:05 ` Tony Lindgren
     [not found] ` <E1SoaE5-0001gM-89@merlin.infradead.org>
2012-07-10 13:42   ` [GIT PULL 5/5] minimal omap5 support " Tony Lindgren
2012-07-10 13:42     ` Tony Lindgren
2012-07-10 15:53     ` Arnd Bergmann
2012-07-10 15:53       ` Arnd Bergmann
2012-07-11  6:04       ` Tony Lindgren [this message]
2012-07-11  6:04         ` Tony Lindgren
2012-07-13  6:14 ` [GIT PULL 1/5] omap device tree changes " Mohammed, Afzal
2012-07-13  6:14   ` Mohammed, Afzal
2012-07-13  6:41   ` Tony Lindgren
2012-07-13  6:41     ` Tony Lindgren
2012-07-13  7:56     ` Tony Lindgren
2012-07-13  7:56       ` Tony Lindgren
2012-08-07  7:13       ` Tony Lindgren
2012-08-07  7:13         ` Tony Lindgren
2012-08-07  7:29         ` Mohammed, Afzal
2012-08-07  7:29           ` Mohammed, Afzal

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=20120711060439.GZ1122@atomide.com \
    --to=tony@atomide.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=olof@lixom.net \
    /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.