| Message ID | 20110727121156.GK10037@game.jcrosoft.org |
|---|---|
| State | New |
| Headers | show |
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
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.
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
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.
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
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.
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.
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,
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.
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.
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.