Patchwork [GIT,PULL] Kirkwood: board changes for v3.7

login
register
mail settings
Submitter Jason
Date Aug. 29, 2012, 12:11 a.m.
Message ID <20120829001129.GO19437@titan.lakedaemon.net>
Download mbox
Permalink /patch/180599/
State New
Headers show

Pull-request

git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2

Comments

Jason - Aug. 29, 2012, 12:11 a.m.
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:

  Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)

are available in the git repository at:
  git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2

Alan M Butler (1):
      ARM: Kirkwood: Iomega ix2-200 DT support

Arnaud Patard (3):
      ARM: Kirkwood: Describe iconnect keys in DT.
      ARM: Kirkwood: Describe iconnect nand in DT.
      ARM: Kirkwood: fix Makefile.boot

Jason Cooper (5):
      ARM: Kirkwood: board-dockstar: use linux/platform_data/mvsdio.h instead of plat/mvsdio.h   
      ARM: Kirkwood: use linux/platform_data/mv643xx.h instead of linux/mv643xx.h
      ARM: Kirkwood: Kconfig: keep DT boards together
      ARM: Kirkwood: update defconfig
      ARM: Kirkwood: add DT boards to defconfig

Sebastian Hesselbarth (2):
      ARM: kirkwood: DT board setup for Seagate FreeAgent Dockstar
      ARM: kirkwood: DT descriptor for Seagate FreeAgent Dockstar

Thomas Petazzoni (15):
      arm: add documentation describing Marvell families of SoC
      mtd: orion_nand: remove <mach/hardware.h> include
      arm: plat-orion: use 'void __iomem *' in addr-map code
      arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option
      arm: plat-orion: make bridge_virt_base non-const to support DT use case
      arm: mvebu: add basic address decoding support to Armada 370/XP
      arm: mvebu: add address decoding controller to the DT
      sound: kirkwood: remove useless <plat/audio.h> include
      sound: kirkwood: move <plat/audio.h> to <linux/platform_data/kirkwood-audio.h>  
      usb: ehci-orion: move <plat/ehci-orion.h> to <linux/platform_data/ehci-orion.h> 
      mmc: mvsdio: move <plat/mvsdio.h> to <linux/platform_data/mvsdio.h>
      dma: mv_xor: move <plat/mv_xor.h> to <linux/platform_data/mv_xor.h>
      mtd: orion_nand: move <plat/orion_nand.h> to <linux/platform_data/orion_nand.h>
      i2c: mv643xx: move <linux/mv643xx_i2c.h> to <linux/platform_data/mv643xx_i2c.h>
      net: mv643xx_eth: move <linux/mv643xx_eth.h> to <linux/platform_data/mv643xx_eth.h>

 Documentation/arm/Marvell/README                   |  232 ++++++++++++++++++++
 arch/arm/Kconfig                                   |   13 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               |    5 +
 arch/arm/boot/dts/kirkwood-dockstar.dts            |   57 +++++
 arch/arm/boot/dts/kirkwood-iconnect.dts            |   50 ++++-
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |  105 +++++++++
 arch/arm/configs/kirkwood_defconfig                |   37 ++--
 arch/arm/mach-dove/addr-map.c                      |    2 +-
 arch/arm/mach-dove/cm-a510.c                       |    2 +-
 arch/arm/mach-dove/common.c                        |    2 +-
 arch/arm/mach-dove/dove-db-setup.c                 |    2 +-
 arch/arm/mach-kirkwood/Kconfig                     |   14 ++
 arch/arm/mach-kirkwood/Makefile                    |    2 +
 arch/arm/mach-kirkwood/Makefile.boot               |    5 +-
 arch/arm/mach-kirkwood/addr-map.c                  |    5 +-
 arch/arm/mach-kirkwood/board-dnskw.c               |    2 +-
 arch/arm/mach-kirkwood/board-dockstar.c            |   61 +++++
 arch/arm/mach-kirkwood/board-dreamplug.c           |    4 +-
 arch/arm/mach-kirkwood/board-dt.c                  |    8 +
 arch/arm/mach-kirkwood/board-goflexnet.c           |    4 +-
 arch/arm/mach-kirkwood/board-ib62x0.c              |    2 +-
 arch/arm/mach-kirkwood/board-iconnect.c            |   49 +----
 arch/arm/mach-kirkwood/board-iomega_ix2_200.c      |   57 +++++
 arch/arm/mach-kirkwood/board-lsxl.c                |    2 +-
 arch/arm/mach-kirkwood/board-ts219.c               |    2 +-
 arch/arm/mach-kirkwood/common.c                    |   12 +-
 arch/arm/mach-kirkwood/common.h                    |   12 +
 arch/arm/mach-kirkwood/d2net_v2-setup.c            |    2 +-
 arch/arm/mach-kirkwood/db88f6281-bp-setup.c        |    4 +-
 arch/arm/mach-kirkwood/dockstar-setup.c            |    4 +-
 arch/arm/mach-kirkwood/guruplug-setup.c            |    4 +-
 arch/arm/mach-kirkwood/mv88f6281gtw_ge-setup.c     |    2 +-
 arch/arm/mach-kirkwood/netspace_v2-setup.c         |    2 +-
 arch/arm/mach-kirkwood/netxbig_v2-setup.c          |    2 +-
 arch/arm/mach-kirkwood/openrd-setup.c              |    4 +-
 arch/arm/mach-kirkwood/rd88f6192-nas-setup.c       |    2 +-
 arch/arm/mach-kirkwood/rd88f6281-setup.c           |    4 +-
 arch/arm/mach-kirkwood/sheevaplug-setup.c          |    4 +-
 arch/arm/mach-kirkwood/t5325-setup.c               |    2 +-
 arch/arm/mach-kirkwood/ts219-setup.c               |    2 +-
 arch/arm/mach-kirkwood/ts41x-setup.c               |    2 +-
 arch/arm/mach-mv78xx0/addr-map.c                   |    4 +-
 arch/arm/mach-mv78xx0/buffalo-wxl-setup.c          |    2 +-
 arch/arm/mach-mv78xx0/common.c                     |    4 +-
 arch/arm/mach-mv78xx0/db78x00-bp-setup.c           |    2 +-
 arch/arm/mach-mv78xx0/rd78x00-masa-setup.c         |    2 +-
 arch/arm/mach-mvebu/Makefile                       |    2 +-
 arch/arm/mach-mvebu/addr-map.c                     |  134 +++++++++++
 arch/arm/mach-orion5x/addr-map.c                   |    5 +-
 arch/arm/mach-orion5x/common.c                     |    6 +-
 arch/arm/mach-orion5x/d2net-setup.c                |    2 +-
 arch/arm/mach-orion5x/db88f5281-setup.c            |    4 +-
 arch/arm/mach-orion5x/dns323-setup.c               |    2 +-
 arch/arm/mach-orion5x/edmini_v2-setup.c            |    2 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c          |    4 +-
 arch/arm/mach-orion5x/ls-chl-setup.c               |    2 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c               |    2 +-
 arch/arm/mach-orion5x/lsmini-setup.c               |    2 +-
 arch/arm/mach-orion5x/mss2-setup.c                 |    2 +-
 arch/arm/mach-orion5x/mv2120-setup.c               |    2 +-
 arch/arm/mach-orion5x/net2big-setup.c              |    2 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c       |    2 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c        |    2 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c            |    2 +-
 arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c       |    2 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c     |    2 +-
 arch/arm/mach-orion5x/ts209-setup.c                |    2 +-
 arch/arm/mach-orion5x/ts409-setup.c                |    2 +-
 arch/arm/mach-orion5x/ts78xx-setup.c               |    2 +-
 arch/arm/mach-orion5x/tsx09-common.c               |    2 +-
 arch/arm/mach-orion5x/wnr854t-setup.c              |    2 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c           |    2 +-
 arch/arm/plat-orion/Makefile                       |    9 +-
 arch/arm/plat-orion/addr-map.c                     |   11 +-
 arch/arm/plat-orion/common.c                       |    8 +-
 arch/arm/plat-orion/include/plat/addr-map.h        |    4 +-
 arch/arm/plat-orion/include/plat/audio.h           |    7 -
 arch/arm/plat-orion/include/plat/common.h          |    2 +-
 drivers/dma/mv_xor.c                               |    2 +-
 drivers/i2c/busses/i2c-mv64xxx.c                   |    2 +-
 drivers/mmc/host/mvsdio.c                          |    2 +-
 drivers/mtd/nand/orion_nand.c                      |    2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c         |    2 +-
 drivers/usb/host/ehci-orion.c                      |    2 +-
 include/linux/mv643xx.h                            |    4 +-
 .../linux/platform_data}/ehci-orion.h              |    6 +-
 include/linux/platform_data/kirkwood-audio.h       |    7 +
 include/linux/{ => platform_data}/mv643xx_eth.h    |    4 +-
 include/linux/{ => platform_data}/mv643xx_i2c.h    |    4 +-
 .../plat => include/linux/platform_data}/mv_xor.h  |    6 +-
 .../plat => include/linux/platform_data}/mvsdio.h  |    6 +-
 .../linux/platform_data}/orion_nand.h              |    6 +-
 sound/soc/kirkwood/kirkwood-i2s.c                  |    2 +-
 sound/soc/kirkwood/kirkwood-openrd.c               |    1 -
 sound/soc/kirkwood/kirkwood-t5325.c                |    1 -
 95 files changed, 890 insertions(+), 207 deletions(-)
 create mode 100644 Documentation/arm/Marvell/README
 create mode 100644 arch/arm/boot/dts/kirkwood-dockstar.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
 create mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
 create mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c
 create mode 100644 arch/arm/mach-mvebu/addr-map.c
 delete mode 100644 arch/arm/plat-orion/include/plat/audio.h
 rename {arch/arm/plat-orion/include/plat => include/linux/platform_data}/ehci-orion.h (78%)
 create mode 100644 include/linux/platform_data/kirkwood-audio.h
 rename include/linux/{ => platform_data}/mv643xx_eth.h (96%)
 rename include/linux/{ => platform_data}/mv643xx_i2c.h (89%)
 rename {arch/arm/plat-orion/include/plat => include/linux/platform_data}/mv_xor.h (77%)
 rename {arch/arm/plat-orion/include/plat => include/linux/platform_data}/mvsdio.h (77%)
 rename {arch/arm/plat-orion/include/plat => include/linux/platform_data}/orion_nand.h (82%)
Olof Johansson - Sept. 5, 2012, 4:34 a.m.
Hi Jason,


On Tue, Aug 28, 2012 at 08:11:29PM -0400, Jason Cooper wrote:
> The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
> 
>   Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
> 
> are available in the git repository at:
>   git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2

Hmm, this branch contains one duplicate patch due to me applying one
straight to our fixes branch ("ARM: Kirkwood: Fix 'SZ_1M' undeclared here
for db88f6281-bp-setup.c"). I also didn't see that mentioned in the pull
request below, so I'm guessing you added it afterwards. There are also a
couple of merge conflicts with other fixes we have already pulled in from
you, it'd be nice if you just based this branch on those fixes instead.

Also, I wonder if I could have you split up this branch a bit more? My
suggestions are below. You can have branches build on top of each other where
there are dependencies, just please point them out when you send the pull
requests.


Let me know if I'm unclear or if there's something that doesn't make sense,
I'll be happy to help.


-Olof


> 
> Alan M Butler (1):
>       ARM: Kirkwood: Iomega ix2-200 DT support

New board, so can stay in boards branch

> 
> Arnaud Patard (3):
>       ARM: Kirkwood: Describe iconnect keys in DT.
>       ARM: Kirkwood: Describe iconnect nand in DT.

dt branch material

>       ARM: Kirkwood: fix Makefile.boot

fixes for 3.6, or fixes-non-critical that we pick up before anything else in
3.7, your choice.

> Jason Cooper (5):
>       ARM: Kirkwood: board-dockstar: use linux/platform_data/mvsdio.h instead of plat/mvsdio.h   
>       ARM: Kirkwood: use linux/platform_data/mv643xx.h instead of linux/mv643xx.h
>       ARM: Kirkwood: Kconfig: keep DT boards together

Those would be cleanup

>       ARM: Kirkwood: update defconfig
>       ARM: Kirkwood: add DT boards to defconfig

defconfig branch

> 
> Sebastian Hesselbarth (2):
>       ARM: kirkwood: DT board setup for Seagate FreeAgent Dockstar
>       ARM: kirkwood: DT descriptor for Seagate FreeAgent Dockstar

new boards, board branch

> 
> Thomas Petazzoni (15):
>       arm: add documentation describing Marvell families of SoC

SoC branch or board branch

>       mtd: orion_nand: remove <mach/hardware.h> include

cleanup

>       arm: plat-orion: use 'void __iomem *' in addr-map code

Hmm, I would prefer if the actual constants were annotated instead of cast in
the code here. See how we handled that on tegra with IOMEM(). That will also
help sparse catch unannotated uses of those constants.

>       arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option

cleanup or soc

>       arm: plat-orion: make bridge_virt_base non-const to support DT use case

Hm, dt I suppose.

>       arm: mvebu: add basic address decoding support to Armada 370/XP
>       arm: mvebu: add address decoding controller to the DT

soc patches, I'd say

>       sound: kirkwood: remove useless <plat/audio.h> include
>       sound: kirkwood: move <plat/audio.h> to <linux/platform_data/kirkwood-audio.h>  
>       usb: ehci-orion: move <plat/ehci-orion.h> to <linux/platform_data/ehci-orion.h> 
>       mmc: mvsdio: move <plat/mvsdio.h> to <linux/platform_data/mvsdio.h>
>       dma: mv_xor: move <plat/mv_xor.h> to <linux/platform_data/mv_xor.h>
>       mtd: orion_nand: move <plat/orion_nand.h> to <linux/platform_data/orion_nand.h>
>       i2c: mv643xx: move <linux/mv643xx_i2c.h> to <linux/platform_data/mv643xx_i2c.h>
>       net: mv643xx_eth: move <linux/mv643xx_eth.h> to <linux/platform_data/mv643xx_eth.h>

All above are cleanup.


-Olof
Jason - Sept. 5, 2012, 11:44 p.m.
Olof,

Thanks for the help!

On Tue, Sep 04, 2012 at 09:34:35PM -0700, Olof Johansson wrote:
> On Tue, Aug 28, 2012 at 08:11:29PM -0400, Jason Cooper wrote:
> > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
> > 
> >   Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
> > 
> > are available in the git repository at:
> >   git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2
> 
> Hmm, this branch contains one duplicate patch due to me applying one
> straight to our fixes branch ("ARM: Kirkwood: Fix 'SZ_1M' undeclared here
> for db88f6281-bp-setup.c"). I also didn't see that mentioned in the pull
> request below, so I'm guessing you added it afterwards. There are also a
> couple of merge conflicts with other fixes we have already pulled in from
> you, it'd be nice if you just based this branch on those fixes instead.
> 
> Also, I wonder if I could have you split up this branch a bit more? My
> suggestions are below. You can have branches build on top of each other where
> there are dependencies, just please point them out when you send the pull
> requests.
> 
> 
> Let me know if I'm unclear or if there's something that doesn't make sense,
> I'll be happy to help.

No problem, but I do have one question.  Say I have two branches,

	fixes
	dt

And then a 'board' patch depends on stuff in both fixes and dt.  If I base
the board branch on fixes, do I 'git merge' the dt branch, 'git
cherry-pick' the dependency (what I did before), or something else I'm
not aware of?

I've avoided 'git merge' up till now because it creates a merge commit,
which feels wrong.  Perhaps I'm wrong here?

All the branch assignments look good, assuming I can figure out the
above question.

> > 
...
> >       arm: plat-orion: use 'void __iomem *' in addr-map code
> 
> Hmm, I would prefer if the actual constants were annotated instead of cast in
> the code here. See how we handled that on tegra with IOMEM(). That will also
> help sparse catch unannotated uses of those constants.
> 

I'll ask Thomas if he can redo this one.

thx,

Jason.
Olof Johansson - Sept. 5, 2012, 11:58 p.m.
Hi,

On Wed, Sep 5, 2012 at 4:44 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> Olof,
>
> Thanks for the help!
>
> On Tue, Sep 04, 2012 at 09:34:35PM -0700, Olof Johansson wrote:
>> On Tue, Aug 28, 2012 at 08:11:29PM -0400, Jason Cooper wrote:
>> > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
>> >
>> >   Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
>> >
>> > are available in the git repository at:
>> >   git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2
>>
>> Hmm, this branch contains one duplicate patch due to me applying one
>> straight to our fixes branch ("ARM: Kirkwood: Fix 'SZ_1M' undeclared here
>> for db88f6281-bp-setup.c"). I also didn't see that mentioned in the pull
>> request below, so I'm guessing you added it afterwards. There are also a
>> couple of merge conflicts with other fixes we have already pulled in from
>> you, it'd be nice if you just based this branch on those fixes instead.
>>
>> Also, I wonder if I could have you split up this branch a bit more? My
>> suggestions are below. You can have branches build on top of each other where
>> there are dependencies, just please point them out when you send the pull
>> requests.
>>
>>
>> Let me know if I'm unclear or if there's something that doesn't make sense,
>> I'll be happy to help.
>
> No problem, but I do have one question.  Say I have two branches,
>
>         fixes
>         dt
>
> And then a 'board' patch depends on stuff in both fixes and dt.  If I base
> the board branch on fixes, do I 'git merge' the dt branch, 'git
> cherry-pick' the dependency (what I did before), or something else I'm
> not aware of?

Merge is the way to go, otherwise you will have new commits with the
same contents in the new branch.

> I've avoided 'git merge' up till now because it creates a merge commit,
> which feels wrong.  Perhaps I'm wrong here?

It depends on what phase of development you're in, but for something
like this it's the perfectly sane thing to do. There's nothing wrong
with a few merge commits to bring in dependencies, etc.

> All the branch assignments look good, assuming I can figure out the
> above question.

Sounds good. I think the above is a sufficient answer but let me know
if you disagree. :-)

>> >       arm: plat-orion: use 'void __iomem *' in addr-map code
>>
>> Hmm, I would prefer if the actual constants were annotated instead of cast in
>> the code here. See how we handled that on tegra with IOMEM(). That will also
>> help sparse catch unannotated uses of those constants.
>>
>
> I'll ask Thomas if he can redo this one.

Thanks!


-Olof
Jason - Sept. 10, 2012, 5:31 a.m.
On Tue, Sep 04, 2012 at 09:34:35PM -0700, Olof Johansson wrote:
> Hi Jason,
> 
> 
> On Tue, Aug 28, 2012 at 08:11:29PM -0400, Jason Cooper wrote:
> > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
> > 
> >   Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
> > 
> > are available in the git repository at:
> >   git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2
> 
> Hmm, this branch contains one duplicate patch due to me applying one
> straight to our fixes branch ("ARM: Kirkwood: Fix 'SZ_1M' undeclared here
> for db88f6281-bp-setup.c"). I also didn't see that mentioned in the pull
> request below, so I'm guessing you added it afterwards. There are also a
> couple of merge conflicts with other fixes we have already pulled in from
> you, it'd be nice if you just based this branch on those fixes instead.

I'm issuing new pull-requests broken up as you suggested, based on
v3.6-rc5, which incorporates my previous 'fixes-for-v3.6*' pull request.
So, hopefully it should go much better. ;-)

> Also, I wonder if I could have you split up this branch a bit more? My
> suggestions are below. You can have branches build on top of each other where
> there are dependencies, just please point them out when you send the pull
> requests.

Done.

Migration from previous monolithic branch is as follows:

> > 
> > Alan M Butler (1):
> >       ARM: Kirkwood: Iomega ix2-200 DT support
> 
> New board, so can stay in boards branch

Done, kirkwood/boards

> > Arnaud Patard (3):
> >       ARM: Kirkwood: Describe iconnect keys in DT.
> >       ARM: Kirkwood: Describe iconnect nand in DT.
> 
> dt branch material

Done, kirkwood/dt

> >       ARM: Kirkwood: fix Makefile.boot
> 
> fixes for 3.6, or fixes-non-critical that we pick up before anything else in
> 3.7, your choice.

dropped from PR, it's in v3.6-rc5

> > Jason Cooper (5):
> >       ARM: Kirkwood: board-dockstar: use linux/platform_data/mvsdio.h instead of plat/mvsdio.h   
> >       ARM: Kirkwood: use linux/platform_data/mv643xx.h instead of linux/mv643xx.h
> >       ARM: Kirkwood: Kconfig: keep DT boards together
> 
> Those would be cleanup

Done, kirkwood/cleanup.  Except #3 (keep DT boards together), I had to
edit the original patch anyway (submitter new to git), so I incorporated
the change in the original patch.  It was purely menuconfig cosmetic.

> >       ARM: Kirkwood: update defconfig
> >       ARM: Kirkwood: add DT boards to defconfig
> 
> defconfig branch

Done, kirkwood/defconfig.  Updated to include km_kirkwood.

> > Sebastian Hesselbarth (2):
> >       ARM: kirkwood: DT board setup for Seagate FreeAgent Dockstar
> >       ARM: kirkwood: DT descriptor for Seagate FreeAgent Dockstar
> 
> new boards, board branch

Done, kirkwood/boards.

> > Thomas Petazzoni (15):
> >       arm: add documentation describing Marvell families of SoC
> 
> SoC branch or board branch

Done, kirkwood/boards.
 
> >       mtd: orion_nand: remove <mach/hardware.h> include
> 
> cleanup

Taken in via l2-mtd.git, so dropped from my branches, will note the
dependency.

> >       arm: plat-orion: use 'void __iomem *' in addr-map code
> 
> Hmm, I would prefer if the actual constants were annotated instead of cast in
> the code here. See how we handled that on tegra with IOMEM(). That will also
> help sparse catch unannotated uses of those constants.
> 
> >       arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option
> 
> cleanup or soc
> 
> >       arm: plat-orion: make bridge_virt_base non-const to support DT use case
> 
> Hm, dt I suppose.
> 
> >       arm: mvebu: add basic address decoding support to Armada 370/XP
> >       arm: mvebu: add address decoding controller to the DT
> 
> soc patches, I'd say

The above block was one series.  They have been dropped until Thomas can
respond to your comment.

> >       sound: kirkwood: remove useless <plat/audio.h> include
> >       sound: kirkwood: move <plat/audio.h> to <linux/platform_data/kirkwood-audio.h>  
> >       usb: ehci-orion: move <plat/ehci-orion.h> to <linux/platform_data/ehci-orion.h> 
> >       mmc: mvsdio: move <plat/mvsdio.h> to <linux/platform_data/mvsdio.h>
> >       dma: mv_xor: move <plat/mv_xor.h> to <linux/platform_data/mv_xor.h>
> >       mtd: orion_nand: move <plat/orion_nand.h> to <linux/platform_data/orion_nand.h>
> >       i2c: mv643xx: move <linux/mv643xx_i2c.h> to <linux/platform_data/mv643xx_i2c.h>
> >       net: mv643xx_eth: move <linux/mv643xx_eth.h> to <linux/platform_data/mv643xx_eth.h>
> 
> All above are cleanup.

Done, kirkwood/cleanup.

thx,

Jason.
Olof Johansson - Sept. 13, 2012, 5:30 a.m.
On Mon, Sep 10, 2012 at 01:48:35AM -0400, Jason Cooper wrote:
> Arnd, Olof,
> 
> This branch depends on arm/cache-l2x0 which is going in through rmk's
> tree.  arm/cache-l2x0 contains the following from Gregory Clement:
> 
> 	arm: cache-l2x0: make outer_cache_fns a field of l2x0_of_data
> 	arm: cache-l2x0: add an optional register to save/restore

Ok, we need to make sure that Russell is happy with the patches and
is pulling them in (with an agreement to not rebase the merged branch)
before we can pull in your branch that builds on it.

Russell, please let us know if/when that's the case so we can merge in the
dependent code.

Thanks!


-Olof
Jason - Sept. 18, 2012, 5:24 p.m.
On Wed, Sep 12, 2012 at 10:30:45PM -0700, Olof Johansson wrote:
> On Mon, Sep 10, 2012 at 01:48:35AM -0400, Jason Cooper wrote:
> > Arnd, Olof,
> > 
> > This branch depends on arm/cache-l2x0 which is going in through rmk's
> > tree.  arm/cache-l2x0 contains the following from Gregory Clement:
> > 
> > 	arm: cache-l2x0: make outer_cache_fns a field of l2x0_of_data
> > 	arm: cache-l2x0: add an optional register to save/restore
> 
> Ok, we need to make sure that Russell is happy with the patches and
> is pulling them in (with an agreement to not rebase the merged branch)
> before we can pull in your branch that builds on it.

Arnd, Olof,

Ok, I'm still mastering the art of branch dependencies.  The acceptance
of Gregory's cache-l2x0 series is holding up everything else.
Rightfully so, rmk has some issues with it.

However, in my pullrqs and in my branch merging I treated it as a
dependency for everything that came after it (pr 1,2,3,4).  I'd like to
undo that now to get things moving.  The dependency was not strictly
necessary, I was simply trying to achieve an ordering of branches.

The only way I know to do this is to redo my branches and republish.
Basically, I would remove Gregory's patches and the dependency on 'arm:
cache-l2x0' from pullrq [1/4] Kirkwood DT bindings.

Obviously, this would break things for folks tracking my branches.
Hopefully anyone crazy enough to track my branches is competent enough
rebase onto the new branches.  Even still, I don't want to mess anyone up.

I think the benefits of getting these patches in for this merge window
outweigh a onetime breaking of my branches.  Is there anything I'm not
considering before I do this?

I'll do the work now, but hold off on pushing or sending new pullrq's
for a day or two or until I hear from you guys.

thx,

Jason.
Arnd Bergmann - Sept. 19, 2012, 1:59 p.m.
On Tuesday 18 September 2012, Jason Cooper wrote:
> Ok, I'm still mastering the art of branch dependencies.  The acceptance
> of Gregory's cache-l2x0 series is holding up everything else.
> Rightfully so, rmk has some issues with it.
> 
> However, in my pullrqs and in my branch merging I treated it as a
> dependency for everything that came after it (pr 1,2,3,4).  I'd like to
> undo that now to get things moving.  The dependency was not strictly
> necessary, I was simply trying to achieve an ordering of branches.
> 
> The only way I know to do this is to redo my branches and republish.
> Basically, I would remove Gregory's patches and the dependency on 'arm:
> cache-l2x0' from pullrq [1/4] Kirkwood DT bindings.

Right, makes sense.

> Obviously, this would break things for folks tracking my branches.
> Hopefully anyone crazy enough to track my branches is competent enough
> rebase onto the new branches.  Even still, I don't want to mess anyone up.
> 
> I think the benefits of getting these patches in for this merge window
> outweigh a onetime breaking of my branches.  Is there anything I'm not
> considering before I do this?
>
> I'll do the work now, but hold off on pushing or sending new pullrq's
> for a day or two or until I hear from you guys.

My rule is normally that I treat any branches coming from subarchitecture
maintainers as unstable until they are merged into arm-soc.
If you haven't promised anyone to keep your branches stable, I see no
problem with rebasing them to avoid the dependency.

	Arnd
Olof Johansson - Sept. 22, 2012, 5:11 a.m.
Hi Jason,

On Fri, Sep 21, 2012 at 03:46:29PM -0400, Jason Cooper wrote:
> The following changes since commit 5b40baee4a39d96d4d6a48a2b2383982912c429b:
> 
>   arm: mvebu: add address decoding controller to the DT (2012-09-21 18:05:29 +0000)
> 
> are available in the git repository at:
>   git://git.infradead.org/users/jcooper/linux.git kirkwood/dt

Looking at this branch, it's much more than just device tree updates.

It introduces the pinctrl driver (and bindings), and the gpio driver (and
bindings). I think it would make more sense to break those two out to separate
topics, and keep the generic DT updates in this branch.

Also, see my comment on the EHCI binding patch. I wasn't going to ask you to
respin the branch to fix/drop that on its own, but if you do rebuild and split
this branch up you might as well delay those patches until the binding has been
fixed.

I'll pull in your branches under staging/* for now so they can get linux-next
coverage until the "real" branches come in.


-Olof
Olof Johansson - Sept. 22, 2012, 5:17 a.m.
On Fri, Sep 21, 2012 at 03:57:14PM -0400, Jason Cooper wrote:
> 
> NOTE:  This branch depends on both kirkwood/boards and kirkwood/dt (and,
> by extension, kirkwood/addr_decode).  Some of that got pulled into this
> summary (kirkwood/boards).  Is this correct?  Sould I be basing the
> pullreq on v3.6-rc5?  That would summarize all three branches.  Doesn't
> seem as useful.

What I tend to do in these cases is that I merge the dependent branches into
a temporary working branch, then merge in the "new" branch on top, and get the
diffstat from the last merge there.

It also looks like the base for this branch is something that is not a full
-rc, please only base your branches on -rcs since that makes merge history much
cleaner and easier to deal with on our side.

So, for example:

git checkout v3.6-rc5
git merge kirkwood/boards
git merge kirkwood/dt

And then you can use that HEAD as the reference in request-pull.


-Olof
Olof Johansson - Sept. 22, 2012, 5:29 a.m.
On Fri, Sep 21, 2012 at 03:41:41PM -0400, Jason Cooper wrote:
> The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
> 
>   Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
> 
> are available in the git repository at:
>   git://git.infradead.org/users/jcooper/linux.git kirkwood/addr_decode
> 
> Thomas Petazzoni (17):
>       arm: mach-dove: use plus instead of or for address definitions
>       arm: mach-kirkwood: use plus instead of or for address definitions
>       arm: mach-mv78xx0: use plus instead of or for address definitions
>       arm: mach-orion5x: use plus instead of or for address definitions
>       arm: mach-dove: use IOMEM() for base address definitions
>       arm: mach-kirkwood: use IOMEM() for base address definitions
>       arm: mach-mv78xx0: use IOMEM() for base address definitions
>       arm: mach-orion5x: use IOMEM() for base address definitions
>       arm: mach-mvebu: use IOMEM() for base address definitions
>       arm: plat-orion: use void __iomem pointers for UART registration functions
>       arm: plat-orion: use void __iomem pointers for MPP functions
>       arm: plat-orion: use void __iomem pointers for time functions
>       arm: plat-orion: use void __iomem pointers for addr-map functions
>       arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option
>       arm: plat-orion: make bridge_virt_base non-const to support DT use case
>       arm: mvebu: add basic address decoding support to Armada 370/XP
>       arm: mvebu: add address decoding controller to the DT

Hi,

This branch has pretty massive merge conflicts with cleanup/io-pci and other
branches, in particular due to the large number of conflicting cleanup patches.

It'd be better to focus on just the address decoding pieces in this branch, and
move the cleanups to a separate branch. Given the state of affairs w.r.t.
conflicts for the cleanups, saving those for 3.8 might be a better idea.

I mentioned in one of the other comments to a patch in this series that
I was going to pull this in as staging/* and get linux-next coverage,
but these conflicts are more than what I want to deal with now -- so
I'll hold off pulling these in after all.


-Olof
Arnd Bergmann - Sept. 22, 2012, 7:30 a.m.
On Saturday 22 September 2012, Olof Johansson wrote:
> This branch has pretty massive merge conflicts with cleanup/io-pci and other
> branches, in particular due to the large number of conflicting cleanup patches.
> 
> It'd be better to focus on just the address decoding pieces in this branch, and
> move the cleanups to a separate branch. Given the state of affairs w.r.t.
> conflicts for the cleanups, saving those for 3.8 might be a better idea.
> 
> I mentioned in one of the other comments to a patch in this series that
> I was going to pull this in as staging/* and get linux-next coverage,
> but these conflicts are more than what I want to deal with now -- so
> I'll hold off pulling these in after all.

I think the branch is needed though, to avoid lots of build warnings
when the changes to asm/io.h from Russell's tree hit mainline. I did similar
patches for most of the other platforms but left out the ones that I knew
Thomas was already working on.

	Arnd
Thomas Petazzoni - Sept. 22, 2012, 8:20 a.m.
Dear Olof Johansson,

On Fri, 21 Sep 2012 22:29:04 -0700, Olof Johansson wrote:

> This branch has pretty massive merge conflicts with cleanup/io-pci
> and other branches, in particular due to the large number of
> conflicting cleanup patches.
> 
> It'd be better to focus on just the address decoding pieces in this
> branch, and move the cleanups to a separate branch. Given the state
> of affairs w.r.t. conflicts for the cleanups, saving those for 3.8
> might be a better idea.
> 
> I mentioned in one of the other comments to a patch in this series
> that I was going to pull this in as staging/* and get linux-next
> coverage, but these conflicts are more than what I want to deal with
> now -- so I'll hold off pulling these in after all.

This is really surprising. Those cleanups were explicitly requested by
Arnd Bergmann during the review process of my address decoding patch
set. The earlier version of this patch set was only doing address
decoding changes, not the IOMEM() cleanup. And Arnd requested the
IOMEM() cleanup to be done as a pre-requisite to the address decoding
changes. I've therefore spent two days last week doing these cleanups
and retesting the address decoding changes, and now you're telling us
exactly the opposite of what Arnd said two weeks ago?

I'm sorry but that doesn't really fair here.

Best regards,

Thomas
Jason - Sept. 22, 2012, 1:21 p.m.
On Fri, Sep 21, 2012 at 10:11:58PM -0700, Olof Johansson wrote:
> Hi Jason,
> 
> On Fri, Sep 21, 2012 at 03:46:29PM -0400, Jason Cooper wrote:
> > The following changes since commit 5b40baee4a39d96d4d6a48a2b2383982912c429b:
> > 
> >   arm: mvebu: add address decoding controller to the DT (2012-09-21 18:05:29 +0000)
> > 
> > are available in the git repository at:
> >   git://git.infradead.org/users/jcooper/linux.git kirkwood/dt
> 
> Looking at this branch, it's much more than just device tree updates.

Ok, my thinking was they (pinctrl and gpio) were devicetree-only
drivers, see below.

> It introduces the pinctrl driver (and bindings), and the gpio driver (and
> bindings). I think it would make more sense to break those two out to separate
> topics, and keep the generic DT updates in this branch.
> 
> Also, see my comment on the EHCI binding patch. I wasn't going to ask you to
> respin the branch to fix/drop that on its own, but if you do rebuild and split
> this branch up you might as well delay those patches until the binding has been
> fixed.

Ok.  I'll split out pinctrl and gpio into a kirkwood/drivers, leave the
rest in /dt, and drop the ehci changes.  /drivers will still depend on
/addr_decode, once you, Arnd, and Thomas work that out.  /dt should have
no deps then.

/cleanup will now depend only on /boards if we're dropping ehci for now.
/defconfig will still only depend on /boards.
/platform_data will still depend on everything kirkwood/*.

So, I take it /boards is ok?

> I'll pull in your branches under staging/* for now so they can get linux-next
> coverage until the "real" branches come in.

Okay, thanks.

thx,

Jason.