| Message ID | 4F4674F2.8090603@atmel.com |
|---|---|
| State | New |
| Headers | show |
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
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,
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
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,
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
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,