Patchwork [GIT,PULL] at91 first cleanup series for 3.4

login
register
mail settings
Submitter Nicolas Ferre
Date Feb. 23, 2012, 5:18 p.m.
Message ID <4F4674F2.8090603@atmel.com>
Download mbox
Permalink /patch/142677/
State New
Headers show

Pull-request

git://github.com/at91linux/linux-at91.git at91-3.4-base2+cleanup

Comments

Nicolas Ferre - Feb. 23, 2012, 5:18 p.m.
Arnd, Olof,

This series removes the at91_sys_read/write() functions that where
used for all System Controller devices. The static offsets that were
used prevented us from compiling several AT91 SoC support in a single
zImage.

The other cleanup is the move of some early console initialization. In
addition, some Makefile.boot modifications have been performed to be
able to make .dtb files.

All this goes on top of current material that is already in arm-soc
git tree (merge of all at91/* branches. You can find it in the same git
tree with at91-3.4-base2 branch name).


The following changes since commit 11a25ea7e4f870a37093258f577e11cec703e37e:

  Merge remote-tracking branch 'armsoc/at91/9x5' into at91-3.4-base2 (2012-02-11 14:33:03 +0100)

are available in the git repository at:


  git://github.com/at91linux/linux-at91.git at91-3.4-base2+cleanup

for you to fetch changes up to d5e5a7f987458f42f24a557a0f4e35f94c43fc09:

  ARM: at91: properly sort dtb files in Makefile.boot (2012-02-23 14:58:00 +0100)

----------------------------------------------------------------
Jean-Christophe PLAGNIOL-VILLARD (18):
      ARM: at91: factorise duplicated at91sam9 idle
      ARM: at91/at91x40: remove use of at91_sys_read/write
      ARM: at91: make matrix register base soc independent
      ARM: at91: make ST (System Timer) soc independent
      ARM: at91/pm_slowclock: rename register to named define
      ARM: at91/pm_slowclock: function slow_clock() accepts parameters
      ARM: at91: move at91rm9200 sdramc defines to at91rm9200_sdramc.h
      ARM: at91: make sdram/ddr register base soc independent
      ARM: at91/pm_slowclock: add runtime detection of memory contoller
      ARM: at91/PMC: make register base soc independent
      ARM: at91/rtc-at91sam9: each SoC can select the RTT device to use
      ARM: at91:rtc/rtc-at91sam9: ioremap register bank
      ARM: at91/rtc-at91sam9: pass the GPBR to use via resources
      ARM: at91: finally drop at91_sys_read/write
      ARM: at91: merge SRAM Memory banks thanks to mirroring
      Atmel: move console default platform_device to serial driver
      ARM: at91/board-dt: drop default console
      ARM: at91: properly sort dtb files in Makefile.boot

Nicolas Ferre (3):
      ARM: at91/ST: remove not needed casts
      ARM: at91/PMC: move assignment out of printf
      ARM: at91: add at91sam9g25ek.dts in Makefile.boot

 arch/arm/mach-at91/Makefile.boot                   |    8 +-
 arch/arm/mach-at91/at91rm9200.c                    |    8 +-
 arch/arm/mach-at91/at91rm9200_devices.c            |   14 +-
 arch/arm/mach-at91/at91rm9200_time.c               |   37 ++-
 arch/arm/mach-at91/at91sam9260.c                   |   23 +-
 arch/arm/mach-at91/at91sam9260_devices.c           |   38 +++-
 arch/arm/mach-at91/at91sam9261.c                   |   10 +-
 arch/arm/mach-at91/at91sam9261_devices.c           |   31 ++-
 arch/arm/mach-at91/at91sam9263.c                   |   11 +-
 arch/arm/mach-at91/at91sam9263_devices.c           |   59 ++++-
 arch/arm/mach-at91/at91sam9_alt_reset.S            |   12 +-
 arch/arm/mach-at91/at91sam9g45.c                   |   11 +-
 arch/arm/mach-at91/at91sam9g45_devices.c           |   31 ++-
 arch/arm/mach-at91/at91sam9g45_reset.S             |   12 +-
 arch/arm/mach-at91/at91sam9rl.c                    |   10 +-
 arch/arm/mach-at91/at91sam9rl_devices.c            |   31 ++-
 arch/arm/mach-at91/at91sam9x5.c                    |    5 +-
 arch/arm/mach-at91/at91x40.c                       |    2 +-
 arch/arm/mach-at91/at91x40_time.c                  |   28 ++-
 arch/arm/mach-at91/board-cpu9krea.c                |    5 +-
 arch/arm/mach-at91/board-cpuat91.c                 |    1 +
 arch/arm/mach-at91/board-dt.c                      |    6 -
 arch/arm/mach-at91/board-eco920.c                  |    5 +-
 arch/arm/mach-at91/board-kb9202.c                  |    1 +
 arch/arm/mach-at91/board-picotux200.c              |    1 +
 arch/arm/mach-at91/board-rm9200dk.c                |    1 +
 arch/arm/mach-at91/board-rm9200ek.c                |    1 +
 arch/arm/mach-at91/board-yl-9200.c                 |    3 +-
 arch/arm/mach-at91/clock.c                         |   88 ++++---
 arch/arm/mach-at91/generic.h                       |   10 +
 arch/arm/mach-at91/include/mach/at91_matrix.h      |   23 ++
 arch/arm/mach-at91/include/mach/at91_pmc.h         |   56 +++--
 arch/arm/mach-at91/include/mach/at91_ramc.h        |   32 +++
 arch/arm/mach-at91/include/mach/at91_st.h          |   32 ++-
 arch/arm/mach-at91/include/mach/at91rm9200.h       |   10 +-
 arch/arm/mach-at91/include/mach/at91rm9200_mc.h    |   58 +----
 .../arm/mach-at91/include/mach/at91rm9200_sdramc.h |   63 +++++
 arch/arm/mach-at91/include/mach/at91sam9260.h      |   14 +-
 .../mach-at91/include/mach/at91sam9260_matrix.h    |   36 ++--
 arch/arm/mach-at91/include/mach/at91sam9261.h      |   10 +-
 .../mach-at91/include/mach/at91sam9261_matrix.h    |   18 +-
 arch/arm/mach-at91/include/mach/at91sam9263.h      |   12 +-
 .../mach-at91/include/mach/at91sam9263_matrix.h    |   74 +++---
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h  |    6 -
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h  |    6 -
 arch/arm/mach-at91/include/mach/at91sam9g45.h      |   12 +-
 .../mach-at91/include/mach/at91sam9g45_matrix.h    |   84 +++---
 arch/arm/mach-at91/include/mach/at91sam9rl.h       |    7 +-
 .../arm/mach-at91/include/mach/at91sam9rl_matrix.h |   42 ++--
 arch/arm/mach-at91/include/mach/at91sam9x5.h       |    5 +-
 arch/arm/mach-at91/include/mach/at91x40.h          |   18 +-
 arch/arm/mach-at91/include/mach/hardware.h         |    3 +-
 arch/arm/mach-at91/include/mach/io.h               |   18 --
 arch/arm/mach-at91/pm.c                            |   35 ++-
 arch/arm/mach-at91/pm.h                            |   11 +-
 arch/arm/mach-at91/pm_slowclock.S                  |  271 ++++++++++----------
 arch/arm/mach-at91/setup.c                         |    9 +
 arch/avr32/mach-at32ap/at32ap700x.c                |    2 -
 drivers/pcmcia/at91_cf.c                           |    5 +-
 drivers/rtc/rtc-at91sam9.c                         |   98 +++-----
 drivers/tty/serial/atmel_serial.c                  |    2 +
 drivers/usb/gadget/at91_udc.c                      |    9 +-
 drivers/usb/gadget/atmel_usba_udc.c                |    6 +-
 drivers/watchdog/at91rm9200_wdt.c                  |    8 +-
 64 files changed, 920 insertions(+), 678 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_matrix.h
 create mode 100644 arch/arm/mach-at91/include/mach/at91_ramc.h
 create mode 100644 arch/arm/mach-at91/include/mach/at91rm9200_sdramc.h

Thanks, best regards,
Arnd Bergmann - Feb. 27, 2012, 5:31 p.m.
On Thursday 23 February 2012, Nicolas Ferre wrote:
> This series removes the at91_sys_read/write() functions that where
> used for all System Controller devices. The static offsets that were
> used prevented us from compiling several AT91 SoC support in a single
> zImage.
> 
> The other cleanup is the move of some early console initialization. In
> addition, some Makefile.boot modifications have been performed to be
> able to make .dtb files.
> 
> All this goes on top of current material that is already in arm-soc
> git tree (merge of all at91/* branches. You can find it in the same git
> tree with at91-3.4-base2 branch name).
> 
> 
> The following changes since commit 11a25ea7e4f870a37093258f577e11cec703e37e:
> 
>   Merge remote-tracking branch 'armsoc/at91/9x5' into at91-3.4-base2 (2012-02-11 14:33:03 +0100)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/at91linux/linux-at91.git at91-3.4-base2+cleanup

Hi Nicolas,

I cannot merge this into the next/cleanup branch because you have based it
on top of a non-cleanup branch. There are three ways out of this:

1. rebase the entire branch on a changeset that only contains upstream and
cleanup branches, and let me deal with merge conflicts against the at91/9x5
branch.

2. Split this series into two parts, with the simple cleanups going directly
in as in 1, but cleanups on top of the at91/9x5 branch get applied to that
branch only.

3. Create a new next/cleanup2 branch with this pull request that I submit
to Linus separately from the other cleanups.

Which one should it be?

I'm also still not entirely happy with the contents because the newly
introduced macros all still use __raw_readl() instead of readl_relaxed(),
and because the rtt setup appears unnecessarily complex while at the same
time still not sufficient for a combined at91 kernel. It would be nice
if those could be fixed, but I would still take the series without changing
the rtt code because we have not really come to a conclusion otherwise
and the series generally moves things into the right direction.

I've applied your series to the staging/cleanup branch for now, which
means it gets into linux-next but I won't send to Linus unless I get
an update.

	Arnd
Nicolas Ferre - Feb. 28, 2012, 11:19 a.m.
On 02/27/2012 06:31 PM, Arnd Bergmann :
> On Thursday 23 February 2012, Nicolas Ferre wrote:
>> This series removes the at91_sys_read/write() functions that where
>> used for all System Controller devices. The static offsets that were
>> used prevented us from compiling several AT91 SoC support in a single
>> zImage.
>>
>> The other cleanup is the move of some early console initialization. In
>> addition, some Makefile.boot modifications have been performed to be
>> able to make .dtb files.
>>
>> All this goes on top of current material that is already in arm-soc
>> git tree (merge of all at91/* branches. You can find it in the same git
>> tree with at91-3.4-base2 branch name).
>>
>>
>> The following changes since commit 11a25ea7e4f870a37093258f577e11cec703e37e:
>>
>>   Merge remote-tracking branch 'armsoc/at91/9x5' into at91-3.4-base2 (2012-02-11 14:33:03 +0100)
>>
>> are available in the git repository at:
>>
>>
>>   git://github.com/at91linux/linux-at91.git at91-3.4-base2+cleanup
> 
> Hi Nicolas,
> 
> I cannot merge this into the next/cleanup branch because you have based it
> on top of a non-cleanup branch. There are three ways out of this:
> 
> 1. rebase the entire branch on a changeset that only contains upstream and
> cleanup branches, and let me deal with merge conflicts against the at91/9x5
> branch.

Not only at91/9x5 branch but also at91/pm_cleanup

> 2. Split this series into two parts, with the simple cleanups going directly
> in as in 1, but cleanups on top of the at91/9x5 branch get applied to that
> branch only.

The issue with this is that we remove entirely some functions: it is the
goal of this series. So it will be difficult to split it...

It bothers me a little bit to artificially split a logical series of
patches just because it should stand on top of unrelated branches...

Yes this series is dependent on material already pulled in arm-soc for
AT91 during this cycle, but I think it is still better to try to
integrate patches "early and often".

> 3. Create a new next/cleanup2 branch with this pull request that I submit
> to Linus separately from the other cleanups.

Yes, maybe it is the way to go. It is very AT91 specific and this
cleanup spread across all AT91 SoCs and platforms. Why not create an
at91/devel branch with all at91 material + this cleanup branch?

The problem that I see now is that it sounds difficult to build
incremental enhancements during a development cycle: for example, I have
several patch series which deals with the device tree that will go on
top of this "cleanup" branch. The questions are: which branch should I
base my work upon? Will you be able to manage those incremental
dependencies as it seems already difficult to deal with what will be the
base of our 3.4 DT work?

> I'm also still not entirely happy with the contents because the newly
> introduced macros all still use __raw_readl() instead of readl_relaxed(),

This "cleanup" series was not meant to modify this in addition to the
removal of at91_sys_xxx() functions. It has already been a long effort
and we do not want to mix all modifications together.
I think that Jean-Christophe already told you that, BTW.

> and because the rtt setup appears unnecessarily complex while at the same
> time still not sufficient for a combined at91 kernel. It would be nice

Well, complexity of this code is pretty low and I do not see a simple
way to deal with this (resource with/without drivers, multiple resources
on some SoC / single on another, etc.).

> if those could be fixed, but I would still take the series without changing
> the rtt code because we have not really come to a conclusion otherwise
> and the series generally moves things into the right direction.

Ok, thanks.

> I've applied your series to the staging/cleanup branch for now, which
> means it gets into linux-next but I won't send to Linus unless I get
> an update.

So, tell me if you can create a next/cleanup2 (or any kind of "devel")
branch with this pull request. In addition, can you please give me
advice for my future work that is dependent on this series (and Grant's
irqdomain work actually)...

Best regards,
Arnd Bergmann - Feb. 28, 2012, 12:18 p.m.
On Tuesday 28 February 2012, Nicolas Ferre wrote:
> On 02/27/2012 06:31 PM, Arnd Bergmann :
> > On Thursday 23 February 2012, Nicolas Ferre wrote:
> > 
> > I cannot merge this into the next/cleanup branch because you have based it
> > on top of a non-cleanup branch. There are three ways out of this:
> > 
> > 1. rebase the entire branch on a changeset that only contains upstream and
> > cleanup branches, and let me deal with merge conflicts against the at91/9x5
> > branch.
> 
> Not only at91/9x5 branch but also at91/pm_cleanup

at91/pm_cleanup is part of the next/cleanup series, so that is fine.
You can have dependencies on anything that is part of the same set
or something that I want to send before, the one thing I cannot handle
is circular dependencies.

> > 2. Split this series into two parts, with the simple cleanups going directly
> > in as in 1, but cleanups on top of the at91/9x5 branch get applied to that
> > branch only.
> 
> The issue with this is that we remove entirely some functions: it is the
> goal of this series. So it will be difficult to split it...
> 
> It bothers me a little bit to artificially split a logical series of
> patches just because it should stand on top of unrelated branches...

Right.

> Yes this series is dependent on material already pulled in arm-soc for
> AT91 during this cycle, but I think it is still better to try to
> integrate patches "early and often".

Yes, definitely.

> > 3. Create a new next/cleanup2 branch with this pull request that I submit
> > to Linus separately from the other cleanups.
> 
> Yes, maybe it is the way to go. It is very AT91 specific and this
> cleanup spread across all AT91 SoCs and platforms. Why not create an
> at91/devel branch with all at91 material + this cleanup branch?
> 
> The problem that I see now is that it sounds difficult to build
> incremental enhancements during a development cycle: for example, I have
> several patch series which deals with the device tree that will go on
> top of this "cleanup" branch. The questions are: which branch should I
> base my work upon? Will you be able to manage those incremental
> dependencies as it seems already difficult to deal with what will be the
> base of our 3.4 DT work?

Incremental dependencies are fine as long as they are not circular.
My goal is to have something at the start of the merge window that
follows a logical structure across all platforms.

Since cleanups tend to be both large and rather obvious, the idea is
to have all cleanups done first, and then build on top of that with
patch series that do something very specific, starting out wiht a
clean implementation.

When you send DT pull requests, there is no problem having them based on
cleanups, and in fact that is very much expected to be the case.
You can also build DT patches on top of soc specific patches, or the other
way round, but not both at the same time because that would be a circular
dependency. 

Have a look at the arch/arm/arm-soc-for-next-contents.txt file
in the arm-soc tree, that lists the branches that we are preparing, their
contents and the dependencies (if any). Right now, there are very few
hard dependencies, meaning that each next/* branch is pretty much standalone.
That is very convenient for me but it typically doesn't last because people
have dependencies. If you send me a branch for next/dt that is based on
the at91/9x5 branch from next/soc, I will record that dependency in there
and we can no longer accept any pull requests for next/soc that are based
on next/dt. However, we already have next/soc2 because that has a dependency
on the external driver-core tree, so other soc specific changes that are
based on dt changes can also go in there. We can have more of those
(next/dt2, next/soc3, next/board2) when needed, but at some point it might
get a bit silly.

> > I'm also still not entirely happy with the contents because the newly
> > introduced macros all still use __raw_readl() instead of readl_relaxed(),
> 
> This "cleanup" series was not meant to modify this in addition to the
> removal of at91_sys_xxx() functions. It has already been a long effort
> and we do not want to mix all modifications together.
> I think that Jean-Christophe already told you that, BTW.

Hmm I think I missed that part. My point was that we try to reduce the number
of instances of __raw_readl. These patches spread them to more places that
will require cleaning up later. I can see how you want to keep the two changes
(__raw_readl -> readl_relaxed and at91_sys_xxx -> at91_yyy_xxx) separate, but
it would be less churn to add one patch first that converts at91_sys_xxx
to use readl_relaxed and then spread that out than converting them all after
the fact.

> > and because the rtt setup appears unnecessarily complex while at the same
> > time still not sufficient for a combined at91 kernel. It would be nice
> 
> Well, complexity of this code is pretty low and I do not see a simple
> way to deal with this (resource with/without drivers, multiple resources
> on some SoC / single on another, etc.).

The main problem here is that the presence of devices is determined by
a CONFIG_* symbol that controls the compilation of the respective
device driver. It would be nicer if the set of devices that is created
on a given board is always the same, but the arbitration between the
drivers is handled independent of which drivers are built into the kernel.

> > I've applied your series to the staging/cleanup branch for now, which
> > means it gets into linux-next but I won't send to Linus unless I get
> > an update.
> 
> So, tell me if you can create a next/cleanup2 (or any kind of "devel")
> branch with this pull request. In addition, can you please give me
> advice for my future work that is dependent on this series (and Grant's
> irqdomain work actually)...

I can do that, which would pin down the following branches:

1. next/fixes-non-critical
2. next/cleanup
3. next/soc
4. next/cleanup2

These can no longer get reordered when I do that, but any other branches are
still independent of these and can be arbitrarily moved around anywhere after
next/cleanup.

We can easily put the irqdomain tree into one of the next/* branches as a
dependency, which causes that particular branch to get delayed until Grant
has got his patches upstream. If you send me a series for next/boards that
depend on irqdomain, I would probably put that into a next/boards2 branch
or into a next/irqdomain branch in case I get similar things from multiple
people. If Grant's patches are already upstream by the time I get to send
out the next/boards branch to Linus, I would probably merge next/boards2
into next/boards and send all of it together.

	Arnd
Nicolas Ferre - Feb. 29, 2012, 9:40 a.m.
On 02/28/2012 01:18 PM, Arnd Bergmann :
> On Tuesday 28 February 2012, Nicolas Ferre wrote:

[..]

>>> I'm also still not entirely happy with the contents because the newly
>>> introduced macros all still use __raw_readl() instead of readl_relaxed(),
>>
>> This "cleanup" series was not meant to modify this in addition to the
>> removal of at91_sys_xxx() functions. It has already been a long effort
>> and we do not want to mix all modifications together.
>> I think that Jean-Christophe already told you that, BTW.
> 
> Hmm I think I missed that part. My point was that we try to reduce the number
> of instances of __raw_readl. These patches spread them to more places that
> will require cleaning up later. I can see how you want to keep the two changes
> (__raw_readl -> readl_relaxed and at91_sys_xxx -> at91_yyy_xxx) separate, but
> it would be less churn to add one patch first that converts at91_sys_xxx
> to use readl_relaxed and then spread that out than converting them all after
> the fact.

Yes, indeed that would have been a good way to proceed but
unfortunately, this at91_sys_xxx() removal action has begun a while ago
(mainline patches that I can link to this action are from Sept. 2011).
We did not have in mind this move from __raw_xxxx() to xxxx_relaxed() at
that time. Jean-Christophe wanted and still want to finish this action
before switching to those new functions and I agree with him.

We discussed together and decided to move to xxxx_relaxed() in the core
AT91 for early 3.5 development cycle. There will be more to convert, but
it will be safer at that time.

>>> and because the rtt setup appears unnecessarily complex while at the same
>>> time still not sufficient for a combined at91 kernel. It would be nice
>>
>> Well, complexity of this code is pretty low and I do not see a simple
>> way to deal with this (resource with/without drivers, multiple resources
>> on some SoC / single on another, etc.).
> 
> The main problem here is that the presence of devices is determined by
> a CONFIG_* symbol that controls the compilation of the respective
> device driver. It would be nicer if the set of devices that is created
> on a given board is always the same, but the arbitration between the
> drivers is handled independent of which drivers are built into the kernel.
> 
>>> I've applied your series to the staging/cleanup branch for now, which
>>> means it gets into linux-next but I won't send to Linus unless I get
>>> an update.
>>
>> So, tell me if you can create a next/cleanup2 (or any kind of "devel")
>> branch with this pull request. In addition, can you please give me
>> advice for my future work that is dependent on this series (and Grant's
>> irqdomain work actually)...
> 
> I can do that, which would pin down the following branches:
> 
> 1. next/fixes-non-critical
> 2. next/cleanup
> 3. next/soc
> 4. next/cleanup2
> 
> These can no longer get reordered when I do that, but any other branches are
> still independent of these and can be arbitrarily moved around anywhere after
> next/cleanup2.

Ok, I understand your point and all the implications. But the problem
with at91/9x5 branch is that it is a product introduction and it is our
responsibility to no leave it on the side. This material represents in
fact a kind of "base" for our 3.4 development (second step "base" actually).

So if you can create this next/cleanup2, please do: it will help us a
lot. I have created a rebased branch which only relies on
at91/pm_cleanup and at91/9x5 here:

git://github.com/at91linux/linux-at91.git at91-3.4-for_cleanup2

(do you want me to send you another pull request?)


> We can easily put the irqdomain tree into one of the next/* branches as a
> dependency, which causes that particular branch to get delayed until Grant
> has got his patches upstream. If you send me a series for next/boards that
> depend on irqdomain, I would probably put that into a next/boards2 branch
> or into a next/irqdomain branch in case I get similar things from multiple
> people. If Grant's patches are already upstream by the time I get to send
> out the next/boards branch to Linus, I would probably merge next/boards2
> into next/boards and send all of it together.

Ok, we will be able to give you AT91 subsequent development based on
both next/cleanup2 and the future next/irqdomain. So you can forget the
other pull request I have sent some days ago:
"[GIT PULL] at91: irqdomain and device tree for AIC and GPIO"
I will rebase it once you will publish the two branches cited above.

Thanks for your patience and understanding. Best regards,
Arnd Bergmann - Feb. 29, 2012, 12:15 p.m.
On Wednesday 29 February 2012, Nicolas Ferre wrote:
> On 02/28/2012 01:18 PM, Arnd Bergmann :
> > On Tuesday 28 February 2012, Nicolas Ferre wrote:

> > Hmm I think I missed that part. My point was that we try to reduce the number
> > of instances of __raw_readl. These patches spread them to more places that
> > will require cleaning up later. I can see how you want to keep the two changes
> > (__raw_readl -> readl_relaxed and at91_sys_xxx -> at91_yyy_xxx) separate, but
> > it would be less churn to add one patch first that converts at91_sys_xxx
> > to use readl_relaxed and then spread that out than converting them all after
> > the fact.
> 
> Yes, indeed that would have been a good way to proceed but
> unfortunately, this at91_sys_xxx() removal action has begun a while ago
> (mainline patches that I can link to this action are from Sept. 2011).
> We did not have in mind this move from __raw_xxxx() to xxxx_relaxed() at
> that time. Jean-Christophe wanted and still want to finish this action
> before switching to those new functions and I agree with him.
> 
> We discussed together and decided to move to xxxx_relaxed() in the core
> AT91 for early 3.5 development cycle. There will be more to convert, but
> it will be safer at that time.

Ok, sounds good.

> > These can no longer get reordered when I do that, but any other branches are
> > still independent of these and can be arbitrarily moved around anywhere after
> > next/cleanup2.
> 
> Ok, I understand your point and all the implications. But the problem
> with at91/9x5 branch is that it is a product introduction and it is our
> responsibility to no leave it on the side. This material represents in
> fact a kind of "base" for our 3.4 development (second step "base" actually).
> 
> So if you can create this next/cleanup2, please do: it will help us a
> lot. I have created a rebased branch which only relies on
> at91/pm_cleanup and at91/9x5 here:
> 
> git://github.com/at91linux/linux-at91.git at91-3.4-for_cleanup2

Ok.

> (do you want me to send you another pull request?)

No, I'll just upgrade the staging branch into a proper one.

> > We can easily put the irqdomain tree into one of the next/* branches as a
> > dependency, which causes that particular branch to get delayed until Grant
> > has got his patches upstream. If you send me a series for next/boards that
> > depend on irqdomain, I would probably put that into a next/boards2 branch
> > or into a next/irqdomain branch in case I get similar things from multiple
> > people. If Grant's patches are already upstream by the time I get to send
> > out the next/boards branch to Linus, I would probably merge next/boards2
> > into next/boards and send all of it together.
> 
> Ok, we will be able to give you AT91 subsequent development based on
> both next/cleanup2 and the future next/irqdomain. So you can forget the
> other pull request I have sent some days ago:
> "[GIT PULL] at91: irqdomain and device tree for AIC and GPIO"
> I will rebase it once you will publish the two branches cited above.

Hmm, incidentally I had already forgotten about that one ;-)

FWIW, I think it's better not to pull the branches from arm-soc.git
back into your own tree, just base your future pull requests on the
branches that you sent me earlier. Otherwise we just get extra
merge commits into the history that don't add any information like you
have here:

11a25ea Merge remote-tracking branch 'armsoc/at91/9x5' into at91-3.4-base2
9acacb1 Merge remote-tracking branch 'armsoc/at91/device-board' into at91-3.4-base2
76e8057 Merge branch 'at91-3.4-base+9x5' of git://github.com/at91linux/linux-at91 into at91/9x5
018b5e1 Merge branch 'at91-3.4-base+pm_cleanup' of git://github.com/at91linux/linux-at91 into at91/pm_cleanup
92b0b63 Merge branch 'at91-3.4-base+device_board' of git://github.com/at91linux/linux-at91 into at91/device-board
6848523 Merge branch 'at91-3.4-base' of git://github.com/at91linux/linux-at91 into at91/base

The lower four merges may or may not make sense for the branch, but the
most recent two are rather pointless here.

	Arnd