[PULL] at91 init factorize

[PULL] at91 init factorize

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,


	This patch series factorize the init of the at91 soc and start the
	work to make the at91 capable to choose the soc at runtime instead of
	compile time.

	The next work will be to factorize the device resource registration
	and then switch to the device tree

	please pull

The following changes since commit e371d46ae45488bcb112a99a7de462e9e3aa6764:

  Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 (2011-07-26 18:30:20 -0700)

are available in the git repository at:

  git://github.com/at91linux/linux-2.6-at91.git j/soc-detect

Jean-Christophe PLAGNIOL-VILLARD (8):
      at91: introduce commom AT91_BASE_SYS
      at91: factorize at91 interrupts init to soc
      at91: remove AT91_DBGU offset from dbgu register macro
      at91: use structure to store the current soc
      at91: move clock subsystem init to soc generic init
      at91: move register clocks to soc generic init
      at91: factorize sram init
      at91: add arch specific ioremap support

 arch/arm/mach-at91/Makefile                   |    2 +-
 arch/arm/mach-at91/at91cap9.c                 |   45 +---
 arch/arm/mach-at91/at91rm9200.c               |   47 +---
 arch/arm/mach-at91/at91sam9260.c              |  100 ++-------
 arch/arm/mach-at91/at91sam9261.c              |   62 +-----
 arch/arm/mach-at91/at91sam9263.c              |   51 +----
 arch/arm/mach-at91/at91sam9g45.c              |   45 +---
 arch/arm/mach-at91/at91sam9rl.c               |   59 +----
 arch/arm/mach-at91/board-1arm.c               |   11 +-
 arch/arm/mach-at91/board-afeb-9260v1.c        |   12 +-
 arch/arm/mach-at91/board-cam60.c              |   12 +-
 arch/arm/mach-at91/board-cap9adk.c            |   12 +-
 arch/arm/mach-at91/board-carmeva.c            |   11 +-
 arch/arm/mach-at91/board-cpu9krea.c           |   11 +-
 arch/arm/mach-at91/board-cpuat91.c            |   11 +-
 arch/arm/mach-at91/board-csb337.c             |   11 +-
 arch/arm/mach-at91/board-csb637.c             |   11 +-
 arch/arm/mach-at91/board-eb9200.c             |   11 +-
 arch/arm/mach-at91/board-ecbat91.c            |   11 +-
 arch/arm/mach-at91/board-eco920.c             |   11 +-
 arch/arm/mach-at91/board-flexibity.c          |   11 +-
 arch/arm/mach-at91/board-foxg20.c             |   12 +-
 arch/arm/mach-at91/board-gsia18s.c            |    9 +-
 arch/arm/mach-at91/board-kafa.c               |   11 +-
 arch/arm/mach-at91/board-kb9202.c             |   11 +-
 arch/arm/mach-at91/board-neocore926.c         |   12 +-
 arch/arm/mach-at91/board-pcontrol-g20.c       |   11 +-
 arch/arm/mach-at91/board-picotux200.c         |   11 +-
 arch/arm/mach-at91/board-qil-a9260.c          |   12 +-
 arch/arm/mach-at91/board-rm9200dk.c           |   11 +-
 arch/arm/mach-at91/board-rm9200ek.c           |   11 +-
 arch/arm/mach-at91/board-sam9-l9260.c         |   12 +-
 arch/arm/mach-at91/board-sam9260ek.c          |   12 +-
 arch/arm/mach-at91/board-sam9261ek.c          |   12 +-
 arch/arm/mach-at91/board-sam9263ek.c          |   12 +-
 arch/arm/mach-at91/board-sam9g20ek.c          |   16 +-
 arch/arm/mach-at91/board-sam9m10g45ek.c       |   12 +-
 arch/arm/mach-at91/board-sam9rlek.c           |   12 +-
 arch/arm/mach-at91/board-snapper9260.c        |   11 +-
 arch/arm/mach-at91/board-stamp9g20.c          |   16 +-
 arch/arm/mach-at91/board-usb-a9260.c          |   12 +-
 arch/arm/mach-at91/board-usb-a9263.c          |   12 +-
 arch/arm/mach-at91/board-yl-9200.c            |   12 +-
 arch/arm/mach-at91/generic.h                  |   34 +--
 arch/arm/mach-at91/include/mach/at91_dbgu.h   |   27 ++-
 arch/arm/mach-at91/include/mach/at91cap9.h    |    1 -
 arch/arm/mach-at91/include/mach/at91rm9200.h  |    1 -
 arch/arm/mach-at91/include/mach/at91sam9260.h |    1 -
 arch/arm/mach-at91/include/mach/at91sam9261.h |    1 -
 arch/arm/mach-at91/include/mach/at91sam9263.h |    1 -
 arch/arm/mach-at91/include/mach/at91sam9g45.h |    1 -
 arch/arm/mach-at91/include/mach/at91sam9rl.h  |    1 -
 arch/arm/mach-at91/include/mach/cpu.h         |  159 ++++++++------
 arch/arm/mach-at91/include/mach/debug-macro.S |   14 +-
 arch/arm/mach-at91/include/mach/hardware.h    |   14 ++
 arch/arm/mach-at91/include/mach/io.h          |   16 ++-
 arch/arm/mach-at91/setup.c                    |  297 +++++++++++++++++++++++++
 arch/arm/mach-at91/soc.h                      |   59 +++++
 58 files changed, 701 insertions(+), 745 deletions(-)
 create mode 100644 arch/arm/mach-at91/setup.c
 create mode 100644 arch/arm/mach-at91/soc.h

Best Regards,
J.

[PULL] at91 init factorize

[Arnd Bergmann]

On Wednesday 27 July 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
>         This patch series factorize the init of the at91 soc and start the
>         work to make the at91 capable to choose the soc at runtime instead of
>         compile time.
> 
>         The next work will be to factorize the device resource registration
>         and then switch to the device tree
> 
>         please pull
> 
> The following changes since commit e371d46ae45488bcb112a99a7de462e9e3aa6764:
> 
>   Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 (2011-07-26 18:30:20 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-2.6-at91.git j/soc-detect

The patches look good, but come at an inconvenient time. We're still
in the merge window, so I don't want to add stuff to linux-next yet
that is destined for 3.2, and I have already sent out all the arm-soc
patches for the 3.1 merge window, so I don't really want to send another
round of patches at the last minute.

	Arnd

[PULL] at91 init factorize

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:47 Wed 27 Jul     , Arnd Bergmann wrote:
> On Wednesday 27 July 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >         This patch series factorize the init of the at91 soc and start the
> >         work to make the at91 capable to choose the soc at runtime instead of
> >         compile time.
> > 
> >         The next work will be to factorize the device resource registration
> >         and then switch to the device tree
> > 
> >         please pull
> > 
> > The following changes since commit e371d46ae45488bcb112a99a7de462e9e3aa6764:
> > 
> >   Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 (2011-07-26 18:30:20 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://github.com/at91linux/linux-2.6-at91.git j/soc-detect
> 
> The patches look good, but come at an inconvenient time. We're still
> in the merge window, so I don't want to add stuff to linux-next yet
> that is destined for 3.2, and I have already sent out all the arm-soc
> patches for the 3.1 merge window, so I don't really want to send another
> round of patches at the last minute.
this are waiting ofr 2 release already

and was inthe next last release for more than 1 month

can we have them merge this time

Best Regards,
J.

[PULL] at91 init factorize

[Arnd Bergmann]

On Thursday 28 July 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > The patches look good, but come at an inconvenient time. We're still
> > in the merge window, so I don't want to add stuff to linux-next yet
> > that is destined for 3.2, and I have already sent out all the arm-soc
> > patches for the 3.1 merge window, so I don't really want to send another
> > round of patches at the last minute.
> this are waiting ofr 2 release already
> 
> and was inthe next last release for more than 1 month
> 
> can we have them merge this time

What I don't understand at all is why you are waiting instead of sending
a pull request for all that time then. I've repeatedly given announcements
about the state of the arm-soc tree and asked people to send patches
they want in 3.1, and you actually sent bug fixes that way earlier.

You've had more than enough time before the merge window, and would even
have made an exception if you had sent your stuff a few hours earlier,
before I sent everything to Linus.
Also, the branch you sent me was created on the same day, meaning that
it can't possibly have had a lot of testing (though it looks harmless
enough). When you send a pull request, the patches should always be
based on an -rc or main release to simplify the merge history, and
it's better not to rebase to the latest one if you already have the
patches.

I've put it into the for-next branch now, and rebased to the previous
tag from the upstream kernel (v3.0). I've also fixed up a trivial bug
I noticed the last time I looked at the patches (the extraneous 
at91_readl function).

	Arnd

[PULL] at91 init factorize

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:58 Thu 28 Jul     , Arnd Bergmann wrote:
> On Thursday 28 July 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > The patches look good, but come at an inconvenient time. We're still
> > > in the merge window, so I don't want to add stuff to linux-next yet
> > > that is destined for 3.2, and I have already sent out all the arm-soc
> > > patches for the 3.1 merge window, so I don't really want to send another
> > > round of patches at the last minute.
> > this are waiting ofr 2 release already
> > 
> > and was inthe next last release for more than 1 month
> > 
> > can we have them merge this time
> 
> What I don't understand at all is why you are waiting instead of sending
> a pull request for all that time then. I've repeatedly given announcements
> about the state of the arm-soc tree and asked people to send patches
> they want in 3.1, and you actually sent bug fixes that way earlier
> 
> You've had more than enough time before the merge window, and would even
> have made an exception if you had sent your stuff a few hours earlier,
> before I sent everything to Linus.
> Also, the branch you sent me was created on the same day, meaning that
> it can't possibly have had a lot of testing (though it looks harmless
> enough). When you send a pull request, the patches should always be
> based on an -rc or main release to simplify the merge history, and
> it's better not to rebase to the latest one if you already have the
> patches.
sorry but those patch are 4 motnhs old and yes I rebase the branch to the
current linus tree before send the pull request.

so as the merge is still open and the patches was in the next for more than
one month there no reason to do not pull them for this relese

Best Regards,
J.

[PULL] at91 init factorize

[Nicolas Pitre]

On Sat, 30 Jul 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:

> On 17:58 Thu 28 Jul     , Arnd Bergmann wrote:
> > On Thursday 28 July 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > The patches look good, but come at an inconvenient time. We're still
> > > > in the merge window, so I don't want to add stuff to linux-next yet
> > > > that is destined for 3.2, and I have already sent out all the arm-soc
> > > > patches for the 3.1 merge window, so I don't really want to send another
> > > > round of patches at the last minute.
> > > this are waiting ofr 2 release already
> > > 
> > > and was inthe next last release for more than 1 month
> > > 
> > > can we have them merge this time
> > 
> > What I don't understand at all is why you are waiting instead of sending
> > a pull request for all that time then. I've repeatedly given announcements
> > about the state of the arm-soc tree and asked people to send patches
> > they want in 3.1, and you actually sent bug fixes that way earlier
> > 
> > You've had more than enough time before the merge window, and would even
> > have made an exception if you had sent your stuff a few hours earlier,
> > before I sent everything to Linus.
> > Also, the branch you sent me was created on the same day, meaning that
> > it can't possibly have had a lot of testing (though it looks harmless
> > enough). When you send a pull request, the patches should always be
> > based on an -rc or main release to simplify the merge history, and
> > it's better not to rebase to the latest one if you already have the
> > patches.
> sorry but those patch are 4 motnhs old and yes I rebase the branch to the
> current linus tree before send the pull request.

Please don't do that.  It is best if you keep the same branch content 
identical to what has been tested and validated for a while.

> so as the merge is still open and the patches was in the next for more than
> one month there no reason to do not pull them for this relese

Yes there is a reason: you were invited to submit that pull request much 
sooner i.e. _before_ the merge window opened.  Why didn't you do it a 
month ago?


Nicolas

[PULL] at91 init factorize

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:39 Sat 30 Jul     , Nicolas Pitre wrote:
> On Sat, 30 Jul 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On 17:58 Thu 28 Jul     , Arnd Bergmann wrote:
> > > On Thursday 28 July 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > The patches look good, but come at an inconvenient time. We're still
> > > > > in the merge window, so I don't want to add stuff to linux-next yet
> > > > > that is destined for 3.2, and I have already sent out all the arm-soc
> > > > > patches for the 3.1 merge window, so I don't really want to send another
> > > > > round of patches at the last minute.
> > > > this are waiting ofr 2 release already
> > > > 
> > > > and was inthe next last release for more than 1 month
> > > > 
> > > > can we have them merge this time
> > > 
> > > What I don't understand at all is why you are waiting instead of sending
> > > a pull request for all that time then. I've repeatedly given announcements
> > > about the state of the arm-soc tree and asked people to send patches
> > > they want in 3.1, and you actually sent bug fixes that way earlier
> > > 
> > > You've had more than enough time before the merge window, and would even
> > > have made an exception if you had sent your stuff a few hours earlier,
> > > before I sent everything to Linus.
> > > Also, the branch you sent me was created on the same day, meaning that
> > > it can't possibly have had a lot of testing (though it looks harmless
> > > enough). When you send a pull request, the patches should always be
> > > based on an -rc or main release to simplify the merge history, and
> > > it's better not to rebase to the latest one if you already have the
> > > patches.
> > sorry but those patch are 4 motnhs old and yes I rebase the branch to the
> > current linus tree before send the pull request.
> 
> Please don't do that.  It is best if you keep the same branch content 
> identical to what has been tested and validated for a while.
except I send time to retest it
> 
> > so as the merge is still open and the patches was in the next for more than
> > one month there no reason to do not pull them for this relese
> 
> Yes there is a reason: you were invited to submit that pull request much 
> sooner i.e. _before_ the merge window opened.  Why didn't you do it a 
> month ago?
work on other cleanup for this merge but can not finish them in time

so this work can go other work are pending as they depend on it

let this pull go and theere was no announch that we can not send pull during
the merge windows so if there is such rule we must write a patch and put it in
the ARM tree to specified the ARM merge window otherwise the merge normal
merge window prime

Best Regards,
J.

[PULL] at91 init factorize

[Russell King - ARM Linux]

On Sun, Jul 31, 2011 at 05:44:17AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> let this pull go and theere was no announch that we can not send pull during
> the merge windows so if there is such rule we must write a patch and put it
> in the ARM tree to specified the ARM merge window otherwise the merge normal
> merge window prime

Err, what?  That doesn't parse.

Look - it's a requirement that code for the merge window is in linux-next
prior to the merge window opening.

What that means is that if code has not been in the linux-next tree prior
to the merge window opening, it doesn't get merged during the window, and
has to wait until the end of the merge window.

Moreover, new code must not be added to linux-next _during_ the merge
window by anyone (apart from bug fixes) as that can disrupt sorting out
how trees are merged into Linus' tree.

So, the rule has been for years: code not in linux-next does not get
merged during the merge window.

There's nothing new there.

[PULL] at91 init factorize

[Nicolas Ferre]

On 07/31/2011 05:44 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:39 Sat 30 Jul     , Nicolas Pitre wrote:
>> On Sat, 30 Jul 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>
>>> On 17:58 Thu 28 Jul     , Arnd Bergmann wrote:
>>>> On Thursday 28 July 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>> The patches look good, but come at an inconvenient time. We're still
>>>>>> in the merge window, so I don't want to add stuff to linux-next yet
>>>>>> that is destined for 3.2, and I have already sent out all the arm-soc
>>>>>> patches for the 3.1 merge window, so I don't really want to send another
>>>>>> round of patches at the last minute.
>>>>> this are waiting ofr 2 release already
>>>>>
>>>>> and was inthe next last release for more than 1 month
>>>>>
>>>>> can we have them merge this time
>>>>
>>>> What I don't understand at all is why you are waiting instead of sending
>>>> a pull request for all that time then. I've repeatedly given announcements
>>>> about the state of the arm-soc tree and asked people to send patches
>>>> they want in 3.1, and you actually sent bug fixes that way earlier
>>>>
>>>> You've had more than enough time before the merge window, and would even
>>>> have made an exception if you had sent your stuff a few hours earlier,
>>>> before I sent everything to Linus.
>>>> Also, the branch you sent me was created on the same day, meaning that
>>>> it can't possibly have had a lot of testing (though it looks harmless
>>>> enough). When you send a pull request, the patches should always be
>>>> based on an -rc or main release to simplify the merge history, and
>>>> it's better not to rebase to the latest one if you already have the
>>>> patches.
>>> sorry but those patch are 4 motnhs old and yes I rebase the branch to the
>>> current linus tree before send the pull request.
>>
>> Please don't do that.  It is best if you keep the same branch content
>> identical to what has been tested and validated for a while.
> except I send time to retest it

Jean-Christophe,

There is nothing to say in addition:
1/ Arnd has been kind enough to pull those changes in his tree (even 
correcting little things)
2/ Arnd has been kind enough to send a late pull request to Linus
3/ Linus has merged those changes in his tree.

So there is only one word to tell to those people: thanks guys!

Yes, and maybe one more thing to tell them: next time we will do better...

Bye,
-- 
Nicolas Ferre

[PULL] at91 init factorize

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:12 Sun 31 Jul     , Russell King - ARM Linux wrote:
> On Sun, Jul 31, 2011 at 05:44:17AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > let this pull go and theere was no announch that we can not send pull during
> > the merge windows so if there is such rule we must write a patch and put it
> > in the ARM tree to specified the ARM merge window otherwise the merge normal
> > merge window prime
> 
> Err, what?  That doesn't parse.
> 
> Look - it's a requirement that code for the merge window is in linux-next
> prior to the merge window opening.
> 
> What that means is that if code has not been in the linux-next tree prior
> to the merge window opening, it doesn't get merged during the window, and
> has to wait until the end of the merge window.
> 
> Moreover, new code must not be added to linux-next _during_ the merge
> window by anyone (apart from bug fixes) as that can disrupt sorting out
> how trees are merged into Linus' tree.
> 
> So, the rule has been for years: code not in linux-next does not get
> merged during the merge window.
> 
> There's nothing new there.
Agreed 
this patch series was in the next before for sometimes so I did not see the
issue to merge it

Best Regards,
J.

[PULL] at91 init factorize

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:42 Sun 31 Jul     , Nicolas Ferre wrote:
> On 07/31/2011 05:44 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 14:39 Sat 30 Jul     , Nicolas Pitre wrote:
> >>On Sat, 30 Jul 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>
> >>>On 17:58 Thu 28 Jul     , Arnd Bergmann wrote:
> >>>>On Thursday 28 July 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>>The patches look good, but come at an inconvenient time. We're still
> >>>>>>in the merge window, so I don't want to add stuff to linux-next yet
> >>>>>>that is destined for 3.2, and I have already sent out all the arm-soc
> >>>>>>patches for the 3.1 merge window, so I don't really want to send another
> >>>>>>round of patches at the last minute.
> >>>>>this are waiting ofr 2 release already
> >>>>>
> >>>>>and was inthe next last release for more than 1 month
> >>>>>
> >>>>>can we have them merge this time
> >>>>
> >>>>What I don't understand at all is why you are waiting instead of sending
> >>>>a pull request for all that time then. I've repeatedly given announcements
> >>>>about the state of the arm-soc tree and asked people to send patches
> >>>>they want in 3.1, and you actually sent bug fixes that way earlier
> >>>>
> >>>>You've had more than enough time before the merge window, and would even
> >>>>have made an exception if you had sent your stuff a few hours earlier,
> >>>>before I sent everything to Linus.
> >>>>Also, the branch you sent me was created on the same day, meaning that
> >>>>it can't possibly have had a lot of testing (though it looks harmless
> >>>>enough). When you send a pull request, the patches should always be
> >>>>based on an -rc or main release to simplify the merge history, and
> >>>>it's better not to rebase to the latest one if you already have the
> >>>>patches.
> >>>sorry but those patch are 4 motnhs old and yes I rebase the branch to the
> >>>current linus tree before send the pull request.
> >>
> >>Please don't do that.  It is best if you keep the same branch content
> >>identical to what has been tested and validated for a while.
> >except I send time to retest it
> 
> Jean-Christophe,
> 
> There is nothing to say in addition:
> 1/ Arnd has been kind enough to pull those changes in his tree (even
> correcting little things)
> 2/ Arnd has been kind enough to send a late pull request to Linus
didn't see it
busy on the device cleanup to switch to the DT after

Arnd tks a lat

Best Regards,
J.