| Message ID | 20110928103815.GA8344@e102144-lin.cambridge.arm.com |
|---|---|
| State | New |
| Headers | show |
Arnd, On Wed, Sep 28, 2011 at 11:38:15AM +0100, Will Deacon wrote: > Please pull these DEBUG_LL platform updates for 3.2. You can find the core > updates (actually all resident in arch/arm/Kconfig.debug) in Russell's > for-next branch. [...] > The following changes since commit 589593ec8b1790c0d9ea227a3811f819eff4f977: > Stephen Boyd (1): > ARM: 7097/1: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice > > are available in the git repository at: > > git://linux-arm.org/linux-2.6-wd.git for-arnd My git server has been up and down like a yo-yo recently, so if you tried to pull this and it failed, hopefully it's all been fixed now. Will
On Wednesday 28 September 2011, Will Deacon wrote: > > Hi Arnd, > > Please pull these DEBUG_LL platform updates for 3.2. You can find the core > updates (actually all resident in arch/arm/Kconfig.debug) in Russell's > for-next branch. > > I think Stephen Boyd was planning to move MSM to the new code as well, but > I've not seen any code yet so I guess that can go in later. Hi Will, I've tried to pull this branch, but I'm getting conflicts with patches from the 'CPU mapping platform updates' series you sent me earlier. Any idea what's going on there? I can certainly fix up the conflicts, but my feeling is that there is something wrong on your side and one of the two branches contains stuff from a stale version of Russell's tree. Arnd
Hi Arnd, On Fri, Oct 07, 2011 at 09:51:39PM +0100, Arnd Bergmann wrote: > On Wednesday 28 September 2011, Will Deacon wrote: > > Please pull these DEBUG_LL platform updates for 3.2. You can find the core > > updates (actually all resident in arch/arm/Kconfig.debug) in Russell's > > for-next branch. > > > > I think Stephen Boyd was planning to move MSM to the new code as well, but > > I've not seen any code yet so I guess that can go in later. > > Hi Will, > > I've tried to pull this branch, but I'm getting conflicts with patches > from the 'CPU mapping platform updates' series you sent me earlier. > Any idea what's going on there? Hmm, I expect that I've inadvertently ended up basing my patches on a branch that Russell has rebased. I mentioned this on the list at the time: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/063729.html > I can certainly fix up the conflicts, but my feeling is that there is > something wrong on your side and one of the two branches contains > stuff from a stale version of Russell's tree. It looks like both of the branches [cpu-mapping and debug-ll] may be out of date now. I agree that fixing up the conflicts isn't the way to go here, but I'm unsure what to use as my base. I depend on patches that aren't in Russell's devel-stable branch but are in his for-next branch. The only things I can think of are either: - Wait until everything has settled down, then rebase onto Russell's for-linus branch. This has the disadvantage that conflicts and build breakages won't be detected until very late. - Wait until the dependencies are in mainline, then rebase against that. Disadvantage is that it then takes twice as long to get code upstream. - Send another pull request against an unstable branch and hope it doesn't change. Disadvantage being that we have to keep repeating pull requests against a moving target. I'm not especially fond of any of those though... Do you have any other ideas? Cheers, Will
On Monday 10 October 2011, Will Deacon wrote: > > I can certainly fix up the conflicts, but my feeling is that there is > > something wrong on your side and one of the two branches contains > > stuff from a stale version of Russell's tree. > > It looks like both of the branches [cpu-mapping and debug-ll] may be out of > date now. I agree that fixing up the conflicts isn't the way to go here, but > I'm unsure what to use as my base. I depend on patches that aren't in > Russell's devel-stable branch but are in his for-next branch. > > The only things I can think of are either: > > - Wait until everything has settled down, then rebase onto Russell's > for-linus branch. This has the disadvantage that conflicts and build > breakages won't be detected until very late. > > - Wait until the dependencies are in mainline, then rebase against that. > Disadvantage is that it then takes twice as long to get code upstream. > > - Send another pull request against an unstable branch and hope it doesn't > change. Disadvantage being that we have to keep repeating pull requests > against a moving target. > > I'm not especially fond of any of those though... > > Do you have any other ideas? I think the best solution would be to ask Russell to put all the dependencies into a non-rebasing branch and publish that, or to alternatively merge your patches through his tree instead, with my Ack. Both of these will also have to wait for a few more days until Russell is back online. Can you check if the devel-stable branch in his tree already contains the dependencies? Arnd
On Mon, Oct 10, 2011 at 12:20:24PM +0100, Arnd Bergmann wrote: > On Monday 10 October 2011, Will Deacon wrote: > > Do you have any other ideas? > > I think the best solution would be to ask Russell to put all the dependencies > into a non-rebasing branch and publish that, or to alternatively merge your > patches through his tree instead, with my Ack. I don't think asking Russell to maintain a stable branch for each series scales very well if multiple people are doing cross-platform work at the same time. If he's happy merging platform code via his tree, then I'd prefer to go down that route. In this case, it might make sense to try and catch conflicts between his tree and arm-soc before they hit Linus (I guess -next will take care of this?). > Both of these will also have to wait for a few more days until Russell > is back online. Ok, I wasn't aware that we was away. > Can you check if the devel-stable branch in his tree already contains the > dependencies? I just had a quick look and I can't seem them outside of the unstable for-next branch. Cheers, Will
On Mon, Oct 10, 2011 at 02:32:46PM +0100, Will Deacon wrote: > On Mon, Oct 10, 2011 at 12:20:24PM +0100, Arnd Bergmann wrote: > > On Monday 10 October 2011, Will Deacon wrote: > > > Do you have any other ideas? > > > > I think the best solution would be to ask Russell to put all the dependencies > > into a non-rebasing branch and publish that, or to alternatively merge your > > patches through his tree instead, with my Ack. > > I don't think asking Russell to maintain a stable branch for each series > scales very well if multiple people are doing cross-platform work at the > same time. If he's happy merging platform code via his tree, then I'd prefer > to go down that route. In this case, it might make sense to try and catch > conflicts between his tree and arm-soc before they hit Linus (I guess -next > will take care of this?). > > > Both of these will also have to wait for a few more days until Russell > > is back online. > > Ok, I wasn't aware that we was away. > > > Can you check if the devel-stable branch in his tree already contains the > > dependencies? > > I just had a quick look and I can't seem them outside of the unstable for-next > branch. > I also have a number of patches that imx6q series depends on only showing on rmk's for-next branch, and I have to hold imx6q pull request until these patches show up on some non-rebased tree.
On Monday 10 October 2011, Will Deacon wrote: > On Mon, Oct 10, 2011 at 12:20:24PM +0100, Arnd Bergmann wrote: > > On Monday 10 October 2011, Will Deacon wrote: > > > Do you have any other ideas? > > > > I think the best solution would be to ask Russell to put all the dependencies > > into a non-rebasing branch and publish that, or to alternatively merge your > > patches through his tree instead, with my Ack. > > I don't think asking Russell to maintain a stable branch for each series > scales very well if multiple people are doing cross-platform work at the > same time. If he's happy merging platform code via his tree, then I'd prefer > to go down that route. In this case, it might make sense to try and catch > conflicts between his tree and arm-soc before they hit Linus (I guess -next > will take care of this?). Yes, we can definitely spot the conflicts in linux-next, and it gives us the chance to fix them up, e.g. I can wait with sending the arm-soc branches upstream until Russell's branches are merged, at which point I just pull in the branch that was merged into Linus' tree and resolve all conflicts I get. > > Can you check if the devel-stable branch in his tree already contains the > > dependencies? > > I just had a quick look and I can't seem them outside of the unstable for-next > branch. Ok. I think I'll drop the cpu-mapping branch from arm-soc as well then. Are the patches in Russell's tree true dependencies for your work, or just patches touching the same files? If you can send me a branch that contains only your work without any of the patches that are in an unstable branch on Russell's side, I could also take them into arm-soc and take care of the conflicts together with Stephen. Arnd
On Tue, Oct 11, 2011 at 02:33:50PM +0100, Arnd Bergmann wrote: > On Monday 10 October 2011, Will Deacon wrote: > > I don't think asking Russell to maintain a stable branch for each series > > scales very well if multiple people are doing cross-platform work at the > > same time. If he's happy merging platform code via his tree, then I'd prefer > > to go down that route. In this case, it might make sense to try and catch > > conflicts between his tree and arm-soc before they hit Linus (I guess -next > > will take care of this?). > > Yes, we can definitely spot the conflicts in linux-next, and it gives us > the chance to fix them up, e.g. I can wait with sending the arm-soc > branches upstream until Russell's branches are merged, at which point > I just pull in the branch that was merged into Linus' tree and resolve > all conflicts I get. Ok, that sounds good to me. > > > Can you check if the devel-stable branch in his tree already contains the > > > dependencies? > > > > I just had a quick look and I can't seem them outside of the unstable for-next > > branch. > > Ok. I think I'll drop the cpu-mapping branch from arm-soc as well then. Sure, I'll resubmit it to Russell via the patch system with your ack. I'll do the same for the DEBUG_LL platform updates too. > Are the patches in Russell's tree true dependencies for your work, or just > patches touching the same files? If you can send me a branch that contains > only your work without any of the patches that are in an unstable branch > on Russell's side, I could also take them into arm-soc and take care > of the conflicts together with Stephen. For the cpu-mapping, I depend on: ARM: 7011/1: Add ARM cpu topology definition ARM: 7060/1: smp: populate logical CPU mapping during boot ARM: 7061/1: gic: convert logical CPU numbers into physical numbers which I can only see in Russell's for-next branch. For the debug-ll stuff, I depend on: ARM: 7072/1: debug: use kconfig choice for selecting DEBUG_LL UART and conflict with: ARM: 7097/1: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice ARM: 7096/1: debug: Add UART1 config choices ARM: 7116/1: debug: provide dummy default option for DEBUG_LL UART choice ARM: 7073/1: debug: augment DEBUG_LL Kconfig help to clarify behaviour so it's probably easier to go via Russell this time. Cheers, Will
Just to follow up on this... On Tue, Oct 11, 2011 at 04:09:15PM +0100, Will Deacon wrote: > For the cpu-mapping, I depend on: > > ARM: 7011/1: Add ARM cpu topology definition > ARM: 7060/1: smp: populate logical CPU mapping during boot > ARM: 7061/1: gic: convert logical CPU numbers into physical numbers > > which I can only see in Russell's for-next branch. > > For the debug-ll stuff, I depend on: > > ARM: 7072/1: debug: use kconfig choice for selecting DEBUG_LL UART > > and conflict with: > > ARM: 7097/1: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice > ARM: 7096/1: debug: Add UART1 config choices > ARM: 7116/1: debug: provide dummy default option for DEBUG_LL UART choice > ARM: 7073/1: debug: augment DEBUG_LL Kconfig help to clarify behaviour I've stuck a debug-ll branch and a cpu-mapping branch here: git://github.com/wdeacon/linux-wd.git (I finally gave up with my old broken git server!) These branches are based against -rc9 and I've cherry-picked the dependencies from Russell's for-next branch. I'm not sure that's good for anything, but it at least helps to show what's already in Russell's tree and what's currently outstanding. Will
On Tuesday 11 October 2011 19:48:21 Will Deacon wrote: > On Tue, Oct 11, 2011 at 04:09:15PM +0100, Will Deacon wrote: > > For the cpu-mapping, I depend on: > > > > ARM: 7011/1: Add ARM cpu topology definition > > ARM: 7060/1: smp: populate logical CPU mapping during boot > > ARM: 7061/1: gic: convert logical CPU numbers into physical numbers > > > > which I can only see in Russell's for-next branch. > > > > For the debug-ll stuff, I depend on: > > > > ARM: 7072/1: debug: use kconfig choice for selecting DEBUG_LL UART > > > > and conflict with: > > > > ARM: 7097/1: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice > > ARM: 7096/1: debug: Add UART1 config choices > > ARM: 7116/1: debug: provide dummy default option for DEBUG_LL UART choice > > ARM: 7073/1: debug: augment DEBUG_LL Kconfig help to clarify behaviour > > I've stuck a debug-ll branch and a cpu-mapping branch here: > > git://github.com/wdeacon/linux-wd.git Ok, thanks. > (I finally gave up with my old broken git server!) > > These branches are based against -rc9 and I've cherry-picked the > dependencies from Russell's for-next branch. I'm not sure that's good for > anything, but it at least helps to show what's already in Russell's tree > and what's currently outstanding. I've stuck them into the arm-soc tree for now, so we get linux-next coverage, but I won't send them to Linus this way because then we would get the same commits twice in the history. Russell, would be mind putting the 8 patches that Will listed above into the devel-stable or some other non-rebasing branch so we can rebase Will's patches on top of that? Alternatively, if you prefer you could also throw them out of your tree so I can send them to Linus, or you could pull the two patch series from Will into your arm tree so I can drop them completely. Arnnd
On Tue, 11 Oct 2011, Arnd Bergmann wrote: > I've stuck them into the arm-soc tree for now, so we get linux-next > coverage, but I won't send them to Linus this way because then we > would get the same commits twice in the history. Could you please do the same with the following: git://git.linaro.org/people/nico/linux.git mach_memory_h Russell pulled it at some point, and dropped it due to concerns about repeated conflict resolutions (or so I presume). I just did a test merge between your for-next branch and the above and that looked trivial enough. Nicolas
On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote: > On Tue, 11 Oct 2011, Arnd Bergmann wrote: > > > I've stuck them into the arm-soc tree for now, so we get linux-next > > coverage, but I won't send them to Linus this way because then we > > would get the same commits twice in the history. > > Could you please do the same with the following: > > git://git.linaro.org/people/nico/linux.git mach_memory_h > > Russell pulled it at some point, and dropped it due to concerns about > repeated conflict resolutions (or so I presume). I just did a test > merge between your for-next branch and the above and that looked trivial > enough. Ok, done. Arnd
On Tue, Oct 11, 2011 at 09:25:19PM +0200, Arnd Bergmann wrote: > On Tuesday 11 October 2011 19:48:21 Will Deacon wrote: > > On Tue, Oct 11, 2011 at 04:09:15PM +0100, Will Deacon wrote: > > > For the cpu-mapping, I depend on: > > > > > > ARM: 7011/1: Add ARM cpu topology definition > > > ARM: 7060/1: smp: populate logical CPU mapping during boot > > > ARM: 7061/1: gic: convert logical CPU numbers into physical numbers > > > > > > which I can only see in Russell's for-next branch. > > > > > > For the debug-ll stuff, I depend on: > > > > > > ARM: 7072/1: debug: use kconfig choice for selecting DEBUG_LL UART > > > > > > and conflict with: > > > > > > ARM: 7097/1: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice > > > ARM: 7096/1: debug: Add UART1 config choices > > > ARM: 7116/1: debug: provide dummy default option for DEBUG_LL UART choice > > > ARM: 7073/1: debug: augment DEBUG_LL Kconfig help to clarify behaviour > > > > I've stuck a debug-ll branch and a cpu-mapping branch here: > > > > git://github.com/wdeacon/linux-wd.git > > Ok, thanks. > > > (I finally gave up with my old broken git server!) > > > > These branches are based against -rc9 and I've cherry-picked the > > dependencies from Russell's for-next branch. I'm not sure that's good for > > anything, but it at least helps to show what's already in Russell's tree > > and what's currently outstanding. > > I've stuck them into the arm-soc tree for now, so we get linux-next > coverage, but I won't send them to Linus this way because then we > would get the same commits twice in the history. > > Russell, would be mind putting the 8 patches that Will listed above > into the devel-stable or some other non-rebasing branch so we can > rebase Will's patches on top of that? > > Alternatively, if you prefer you could also throw them out of your > tree so I can send them to Linus, or you could pull the two patch > series from Will into your arm tree so I can drop them completely. At this point in the game (which I guess is that the merge window is very likely going to open this evening), I'm minded to just say no, my tree is now frozen, and that's that - especially as there's a bunch of _horrible_ merges involved in rebuilding that stuff now. Especially as its going to take me a few days before I start looking at touching my git tree as I'll be sorting through the email backlog.
Hi Russell, On Wed, Oct 12, 2011 at 06:29:25PM +0100, Russell King - ARM Linux wrote: > On Tue, Oct 11, 2011 at 09:25:19PM +0200, Arnd Bergmann wrote: > > Russell, would be mind putting the 8 patches that Will listed above > > into the devel-stable or some other non-rebasing branch so we can > > rebase Will's patches on top of that? > > > > Alternatively, if you prefer you could also throw them out of your > > tree so I can send them to Linus, or you could pull the two patch > > series from Will into your arm tree so I can drop them completely. > > At this point in the game (which I guess is that the merge window is > very likely going to open this evening), I'm minded to just say no, my > tree is now frozen, and that's that - especially as there's a bunch of > _horrible_ merges involved in rebuilding that stuff now. > > Especially as its going to take me a few days before I start looking > at touching my git tree as I'll be sorting through the email backlog. OK, that's understandable. Does this mean that your for-next branch is what will be going to Linus when the merge window opens? If so, I can rebase onto that now that it's frozen and Arnd can pull in the platform bits to arm-soc. Cheers, Will
On Wed, Oct 12, 2011 at 06:35:23PM +0100, Will Deacon wrote: > OK, that's understandable. Does this mean that your for-next branch is what > will be going to Linus when the merge window opens? If so, I can rebase onto > that now that it's frozen and Arnd can pull in the platform bits to arm-soc. Given that I've only been back for less than an hour, I can't say very much because I don't know what the current state of anything is yet. That's more the message I wanted to convey at the moment.
On Wed, Oct 12, 2011 at 07:01:55PM +0100, Russell King - ARM Linux wrote: > On Wed, Oct 12, 2011 at 06:35:23PM +0100, Will Deacon wrote: > > OK, that's understandable. Does this mean that your for-next branch is what > > will be going to Linus when the merge window opens? If so, I can rebase onto > > that now that it's frozen and Arnd can pull in the platform bits to arm-soc. > > Given that I've only been back for less than an hour, I can't say very > much because I don't know what the current state of anything is yet. > That's more the message I wanted to convey at the moment. Right, I'll hold my horses 'til things have settled down then. Thanks, Will
On Wed, 12 Oct 2011, Jamie Iles wrote: > Hi Nicolas, > > On Tue, Oct 11, 2011 at 08:03:38PM -0400, Nicolas Pitre wrote: > > On Tue, 11 Oct 2011, Arnd Bergmann wrote: > > > > > I've stuck them into the arm-soc tree for now, so we get linux-next > > > coverage, but I won't send them to Linus this way because then we > > > would get the same commits twice in the history. > > > > Could you please do the same with the following: > > > > git://git.linaro.org/people/nico/linux.git mach_memory_h > > > > Russell pulled it at some point, and dropped it due to concerns about > > repeated conflict resolutions (or so I presume). I just did a test > > merge between your for-next branch and the above and that looked trivial > > enough. > > I just had a quick look at this branch as picoxcell has just been merged > with an empty memory.h. I'll submit a patch to remove that, but I just > noticed in "ARM: switch from NO_MACH_MEMORY_H to NEED_MACH_MEMORY_H" > there is this hunk: > > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig > index e00fe76..6d49d2f1d 100644 > --- a/arch/arm/plat-omap/Kconfig > +++ b/arch/arm/plat-omap/Kconfig > @@ -14,6 +14,7 @@ config ARCH_OMAP1 > select CLKDEV_LOOKUP > select CLKSRC_MMIO > select GENERIC_IRQ_CHIP > + select HAVE_MACH_MEMORY_H > help > "Systems based on omap7xx, omap15xx or omap16xx" > > and I think that should be "select NEED_MACH_MEMORY_H" instead. Indeed, good catch. I've updated my branch with that fix. Nicolas
On Tue, Oct 11, 2011 at 08:03:38PM -0400, Nicolas Pitre wrote: > On Tue, 11 Oct 2011, Arnd Bergmann wrote: > > > I've stuck them into the arm-soc tree for now, so we get linux-next > > coverage, but I won't send them to Linus this way because then we > > would get the same commits twice in the history. > > Could you please do the same with the following: > > git://git.linaro.org/people/nico/linux.git mach_memory_h > > Russell pulled it at some point, and dropped it due to concerns about > repeated conflict resolutions (or so I presume). I just did a test > merge between your for-next branch and the above and that looked trivial > enough. _and_ the breakage of the ZBOOT_ROM stuff. So I'm now interpreting your request to Arnd to pull it as an attempt to bypass me. That's not what arm-soc is supposed to be about, and that's certainly not what Linaro is supposed to be doing. If that's how you want to behave, I'm disgusted, and be prepared for your work to become a lot harder in the future.
On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote: > On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote: > > On Tue, 11 Oct 2011, Arnd Bergmann wrote: > > > > > I've stuck them into the arm-soc tree for now, so we get linux-next > > > coverage, but I won't send them to Linus this way because then we > > > would get the same commits twice in the history. > > > > Could you please do the same with the following: > > > > git://git.linaro.org/people/nico/linux.git mach_memory_h > > > > Russell pulled it at some point, and dropped it due to concerns about > > repeated conflict resolutions (or so I presume). I just did a test > > merge between your for-next branch and the above and that looked trivial > > enough. > > Ok, done. Bypassing maintainers stinks - especially when there are unaddressed comments outstanding. Nicolas has "simplified" my objections in this request for you to pull - and has completely ignored the problem that it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx with no way for that to be provided. Moreover, it forces EP93xx to always use AUTO_ZRELADDR, but you can still select ZBOOT_ROM, which is an invalid combination. Not only that, I'm carrying a patch from Sascha which detects the multiple-zreladdr problem and prevents building such kernels and this conflicts with that patch. So I'm not pulling Nicolas' mach_memory_h branch until he comes to his senses. I had pointed this out but got a rather stroppy replies in return.
On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: > On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote: > > On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote: > > > On Tue, 11 Oct 2011, Arnd Bergmann wrote: > > > > > > > I've stuck them into the arm-soc tree for now, so we get linux-next > > > > coverage, but I won't send them to Linus this way because then we > > > > would get the same commits twice in the history. > > > > > > Could you please do the same with the following: > > > > > > git://git.linaro.org/people/nico/linux.git mach_memory_h > > > > > > Russell pulled it at some point, and dropped it due to concerns about > > > repeated conflict resolutions (or so I presume). I just did a test > > > merge between your for-next branch and the above and that looked trivial > > > enough. > > > > Ok, done. > > Bypassing maintainers stinks - especially when there are unaddressed > comments outstanding. Nicolas has "simplified" my objections in this > request for you to pull - and has completely ignored the problem that > it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx > with no way for that to be provided. I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that this was approved by the EP93xx maintainers. Furthermore I said that I intended to make ZBOOT_ROM dependent on CONFIG_PHYS_OFFSET, given that PHYS_OFFSEt and zreladdr are intimately related which I also explained previously. This doesn't have to go in right away though. But if this is one of your _requirements_, I'd have appreciated you made it clearer instead of letting me to dry without any feedback, especially when I re-re-re-pinged you last week and before. So much for having lectured me on proper communication. Nicolas
On Thu, Oct 13, 2011 at 09:39:03AM -0400, Nicolas Pitre wrote: > On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: > > > On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote: > > > On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote: > > > > On Tue, 11 Oct 2011, Arnd Bergmann wrote: > > > > > > > > > I've stuck them into the arm-soc tree for now, so we get linux-next > > > > > coverage, but I won't send them to Linus this way because then we > > > > > would get the same commits twice in the history. > > > > > > > > Could you please do the same with the following: > > > > > > > > git://git.linaro.org/people/nico/linux.git mach_memory_h > > > > > > > > Russell pulled it at some point, and dropped it due to concerns about > > > > repeated conflict resolutions (or so I presume). I just did a test > > > > merge between your for-next branch and the above and that looked trivial > > > > enough. > > > > > > Ok, done. > > > > Bypassing maintainers stinks - especially when there are unaddressed > > comments outstanding. Nicolas has "simplified" my objections in this > > request for you to pull - and has completely ignored the problem that > > it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx > > with no way for that to be provided. > > I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that > this was approved by the EP93xx maintainers. It was not even discussed - or even the issue pointed out (I checked). In any case, how can *anyone* know whether ZBOOT_ROM is used or not? It's a facility that's there for users (not really for maintainers) to enable. > Furthermore I said that I intended to make ZBOOT_ROM dependent on > CONFIG_PHYS_OFFSET, given that PHYS_OFFSEt and zreladdr are intimately > related which I also explained previously. Sorry, you're totally confused here - with your own work noless. CONFIG_PHYS_OFFSET is a numeric setting, which is only available when the dynamic p:v stuff is disabled. So, saying that ZBOOT_ROM is dependent on CONFIG_PHYS_OFFSET is insane - it's completely the wrong symbol. So I'm going to assume that you actually meant CONFIG_ARM_PATCH_PHYS_VIRT instead. Now, the *TECHNICAL* point is that there is absolutely nothing wrong with building a kernel with CONFIG_ARM_PATCH_PHYS_VIRT *enabled* and ZBOOT_ROM also enabled. You get a kernel Image which can be loaded at different addresses, and it'll work. You get a zImage which can also be loaded at different addresses, and it'll also work. You can also put the zImage into read-only memory. However, ZBOOT_ROM is completely *INCOMPATIBLE* with AUTO_ZRELADDR. So if anything, ZBOOT_ROM should depend on !AUTO_ZRELADDR *only*. Given your vehement response when I raised that point, you don't want to understand it, so I decided to postpone the issue until I had the motivation to go head-to-head with you like I'm now doing - to make you see sense. Moreover, because you're encouraging maintainers to accept patches which remove the zreladdr definitions and force-select AUTO_ZRELADDR, you're actively killing off ZBOOT_ROM support, even though you said otherwise. I suspect in a years time it won't be worth having anymore - because in order to use it you'd have to hack the select statements out of the Kconfig files. > This doesn't have to go in > right away though. But if this is one of your _requirements_, I'd have > appreciated you made it clearer instead of letting me to dry without any > feedback, especially when I re-re-re-pinged you last week and before. Stop overstating your position. You never 're-re-re-pinged' - you sent _one_ reminder only, which I did think about responding to, but in the end I decided I didn't need any more flames from you at that time (because I wouldn't be around to respond).
On Thursday 13 October 2011, Nicolas Pitre wrote: > On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: > > Bypassing maintainers stinks - especially when there are unaddressed > > comments outstanding. Nicolas has "simplified" my objections in this > > request for you to pull - and has completely ignored the problem that > > it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx > > with no way for that to be provided. I've removed it from the arm-soc for-next branch now and won't push it unless you specifically ask me to. > I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that > this was approved by the EP93xx maintainers. > > Furthermore I said that I intended to make ZBOOT_ROM dependent on > CONFIG_PHYS_OFFSET, given that PHYS_OFFSEt and zreladdr are intimately > related which I also explained previously. This doesn't have to go in > right away though. But if this is one of your _requirements_, I'd have > appreciated you made it clearer instead of letting me to dry without any > feedback, especially when I re-re-re-pinged you last week and before. > > So much for having lectured me on proper communication. There is no point in arguing about who miscommunicated, or in assuming evil intentions. The rule for the arm-soc tree is very simple: if someone asks for a branch to be included and it looks reasonable to me, it goes in. If else someone has reasonable concerns over the code, it gets removed again until the concerns are all resolved. Judging what is reasonable is of course the hard part, but 90% of the time it's pretty obvious. Arnd
On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: > On Thu, Oct 13, 2011 at 09:39:03AM -0400, Nicolas Pitre wrote: > > On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: > > > > > On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote: > > > > On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote: > > > > > On Tue, 11 Oct 2011, Arnd Bergmann wrote: > > > > > > > > > > > I've stuck them into the arm-soc tree for now, so we get linux-next > > > > > > coverage, but I won't send them to Linus this way because then we > > > > > > would get the same commits twice in the history. > > > > > > > > > > Could you please do the same with the following: > > > > > > > > > > git://git.linaro.org/people/nico/linux.git mach_memory_h > > > > > > > > > > Russell pulled it at some point, and dropped it due to concerns about > > > > > repeated conflict resolutions (or so I presume). I just did a test > > > > > merge between your for-next branch and the above and that looked trivial > > > > > enough. > > > > > > > > Ok, done. > > > > > > Bypassing maintainers stinks - especially when there are unaddressed > > > comments outstanding. Nicolas has "simplified" my objections in this > > > request for you to pull - and has completely ignored the problem that > > > it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx > > > with no way for that to be provided. > > > > I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that > > this was approved by the EP93xx maintainers. > > It was not even discussed - or even the issue pointed out (I checked). > In any case, how can *anyone* know whether ZBOOT_ROM is used or not? > It's a facility that's there for users (not really for maintainers) > to enable. Please listen: I have no intention of killing ZBOOT_ROM. If you remember correctly, I was the one who came up with the ability to run the decompressor from ROM in v2.3.23pre5 , before you reworked it with the introduction of ZBOOT_ROM in v2.5.9. I don't know if this feature was ever used by anyone other than myself, but I usually don't tend to scrap my own features. > > Furthermore I said that I intended to make ZBOOT_ROM dependent on > > CONFIG_PHYS_OFFSET, given that PHYS_OFFSEt and zreladdr are intimately > > related which I also explained previously. > > Sorry, you're totally confused here - with your own work noless. > > CONFIG_PHYS_OFFSET is a numeric setting, which is only available when the > dynamic p:v stuff is disabled. So, saying that ZBOOT_ROM is dependent on > CONFIG_PHYS_OFFSET is insane - it's completely the wrong symbol. So I'm > going to assume that you actually meant CONFIG_ARM_PATCH_PHYS_VIRT instead. Not exactly, but that's not the point (see below). > Now, the *TECHNICAL* point is that there is absolutely nothing wrong with > building a kernel with CONFIG_ARM_PATCH_PHYS_VIRT *enabled* and ZBOOT_ROM > also enabled. You get a kernel Image which can be loaded at different > addresses, and it'll work. You get a zImage which can also be loaded at > different addresses, and it'll also work. You can also put the zImage > into read-only memory. We can't agree more on this technical possibility. *BUT* that doesn't mean that because we _can_ do it that this is something useful in practice. > However, ZBOOT_ROM is completely *INCOMPATIBLE* with AUTO_ZRELADDR. So > if anything, ZBOOT_ROM should depend on !AUTO_ZRELADDR *only*. I disagree on two levels. First, practically, there is no advantage to activate ZBOOT_ROM which requires a fixed .bss address and a fixed zreladdr to work, and then have PATCH_PHYS_VIRT also enabled. The purpose of the later is to avoid having a fixed address for RAM encoded in the kernel while the former forces you to know the RAM layout. I just can't find a real life use case where people would want that combination of features. Secondly, zreladdr is really getting in the way of a single zImage for multiple SOCs. And we really want people to get rid of build-time hardcoded constants like zreladdr, PHYS_OFFSET and the like as much as possible. Hence the mach/memory.h removal series. Removing zreladdr is coming next. HOWEVER I don't want to kill the ability to have a XIP kernel, nor do I want to kill ZBOOT_ROM. But let's face it, the people who use either of those features must know what they're doing already. They're obviously the minority users by far, and they should be able to know their hardware sufficiently enough to provide a value for ZBOOT_ROM_TEXT, ZBOOT_ROM_BSS, and/or XIP_PHYS_ADDR. So, given that _practically_ the value in having ZBOOT_ROM and PATCH_PHYS_VIRT together is rather dubious (even if _technically_ this is entirely feasible), I'm looking at using CONFIG_PHYS_OFFSET to get rid of zreladdr because zreladdr is always equal to PHYS_OFFSET + TEXT_OFFSET. Of course that means that ZBOOT_ROM and XIP_KERNEL should then depend on CONFIG_PHYS_OFFSET being configured, which is a consequence of !ARM_PATCH_PHYS_VIRT && !NEED_MACH_MEMORY_H. Or maybe this should be the other way around i.e. ARM_PATCH_PHYS_VIRT depending on !XIP_KERNEL (which is already the case) and !ZBOOT_ROM. But those are Kconfig details that can be discussed later. You are right in saying that, strictly speaking, ZBOOT_ROM should depend on !AUTO_ZRELADDR. But I want AUTO_ZRELADDR to be killed and simply be replaced by #ifndef CONFIG_ZBOOT_ROM in the code eventually, which would implies that (CONFIG_PHYS_OFFSET + TEXT_OFFSET) could be used in the #else part. Why killing it? There is no more obstacles having the AUTO_ZRELADDR feature always enabled by default, except for ZBOOT_ROM. The only problematic platform was MSM because of its 2MB RAM offset, but that limitation has now been removed. > Given your vehement response when I raised that point, you don't want to > understand it, so I decided to postpone the issue until I had the > motivation to go head-to-head with you like I'm now doing - to make you > see sense. Please. I'm not that emotional about what should be a technical discussion. > Moreover, because you're encouraging maintainers to accept patches which > remove the zreladdr definitions and force-select AUTO_ZRELADDR, you're > actively killing off ZBOOT_ROM support, even though you said otherwise. See above. I do want to preserve it, but in a more convenient way from a maintenance perspective. The only difference to the user configuring a kernel with ZBOOT_ROM is that an additional address value (CONFIG_PHYS_OFFSET) will be required, but I think this is a reasonable compromise for this feature. Nicolas
On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: > On Tue, Oct 11, 2011 at 08:03:38PM -0400, Nicolas Pitre wrote: > > On Tue, 11 Oct 2011, Arnd Bergmann wrote: > > > > > I've stuck them into the arm-soc tree for now, so we get linux-next > > > coverage, but I won't send them to Linus this way because then we > > > would get the same commits twice in the history. > > > > Could you please do the same with the following: > > > > git://git.linaro.org/people/nico/linux.git mach_memory_h > > > > Russell pulled it at some point, and dropped it due to concerns about > > repeated conflict resolutions (or so I presume). I just did a test > > merge between your for-next branch and the above and that looked trivial > > enough. > > _and_ the breakage of the ZBOOT_ROM stuff. In order to resolve this impass, I simply dropped the ep93xx patch from the series. This could be revisited later, just like for the StrongARM/XScale cache mapping patches. Pretty please, tell me if there is still something which is not to your satisfaction. > So I'm now interpreting your request to Arnd to pull it as an attempt to > bypass me. That's not what arm-soc is supposed to be about, and that's > certainly not what Linaro is supposed to be doing. Not at all. I asked Arnd to pull it not so this could go to Linus via the arm-soc tree, but rather that this could get increased exposure in both the arm-soc tree and linux-next, and get a feel for the magnitude of the merge conflicts and possible build errors. I'm therefore officially asking you again to pull this series, given that I've removed from it the last offending piece I know about. Nicolas
On 14/10/11 00:39, Nicolas Pitre wrote: > On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: > >> On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote: >>> On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote: >>>> On Tue, 11 Oct 2011, Arnd Bergmann wrote: >>>> >>>>> I've stuck them into the arm-soc tree for now, so we get linux-next >>>>> coverage, but I won't send them to Linus this way because then we >>>>> would get the same commits twice in the history. >>>> >>>> Could you please do the same with the following: >>>> >>>> git://git.linaro.org/people/nico/linux.git mach_memory_h >>>> >>>> Russell pulled it at some point, and dropped it due to concerns about >>>> repeated conflict resolutions (or so I presume). I just did a test >>>> merge between your for-next branch and the above and that looked trivial >>>> enough. >>> >>> Ok, done. >> >> Bypassing maintainers stinks - especially when there are unaddressed >> comments outstanding. Nicolas has "simplified" my objections in this >> request for you to pull - and has completely ignored the problem that >> it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx >> with no way for that to be provided. > > I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that > this was approved by the EP93xx maintainers. As the less active of the two EP93xx maintainers I didn't agree to this. I don't know if Hartley did, but I can't find anything from him in a quick search of the list. I have Cc'ed him. I don't have time to follow this issue in depth, but from my vague understanding ZBOOT_ROM is unlikely to be used on EP93xx, but still _possible_ to use. Therefore we should not be removing support for ZBOOT_ROM on EP93xx in case there are some users out there. ~Ryan
On 14/10/11 10:09, Ryan Mallon wrote: > On 14/10/11 00:39, Nicolas Pitre wrote: > >> On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: >> >>> On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote: >>>> On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote: >>>>> On Tue, 11 Oct 2011, Arnd Bergmann wrote: >>>>> >>>>>> I've stuck them into the arm-soc tree for now, so we get linux-next >>>>>> coverage, but I won't send them to Linus this way because then we >>>>>> would get the same commits twice in the history. >>>>> >>>>> Could you please do the same with the following: >>>>> >>>>> git://git.linaro.org/people/nico/linux.git mach_memory_h >>>>> >>>>> Russell pulled it at some point, and dropped it due to concerns about >>>>> repeated conflict resolutions (or so I presume). I just did a test >>>>> merge between your for-next branch and the above and that looked trivial >>>>> enough. >>>> >>>> Ok, done. >>> >>> Bypassing maintainers stinks - especially when there are unaddressed >>> comments outstanding. Nicolas has "simplified" my objections in this >>> request for you to pull - and has completely ignored the problem that >>> it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx >>> with no way for that to be provided. >> >> I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that >> this was approved by the EP93xx maintainers. > > > As the less active of the two EP93xx maintainers I didn't agree to this. > I don't know if Hartley did, but I can't find anything from him in a > quick search of the list. I have Cc'ed him. > > I don't have time to follow this issue in depth, but from my vague > understanding ZBOOT_ROM is unlikely to be used on EP93xx, but still > _possible_ to use. Therefore we should not be removing support for > ZBOOT_ROM on EP93xx in case there are some users out there. Also, I am on holiday for the next two weeks, so may not be contactable via email. Just wanted to point out that I had not been aware of this issue. ~Ryan
On Fri, 14 Oct 2011, Ryan Mallon wrote: > On 14/10/11 00:39, Nicolas Pitre wrote: > > > On Thu, 13 Oct 2011, Russell King - ARM Linux wrote: > > > >> On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote: > >>> On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote: > >>>> On Tue, 11 Oct 2011, Arnd Bergmann wrote: > >>>> > >>>>> I've stuck them into the arm-soc tree for now, so we get linux-next > >>>>> coverage, but I won't send them to Linus this way because then we > >>>>> would get the same commits twice in the history. > >>>> > >>>> Could you please do the same with the following: > >>>> > >>>> git://git.linaro.org/people/nico/linux.git mach_memory_h > >>>> > >>>> Russell pulled it at some point, and dropped it due to concerns about > >>>> repeated conflict resolutions (or so I presume). I just did a test > >>>> merge between your for-next branch and the above and that looked trivial > >>>> enough. > >>> > >>> Ok, done. > >> > >> Bypassing maintainers stinks - especially when there are unaddressed > >> comments outstanding. Nicolas has "simplified" my objections in this > >> request for you to pull - and has completely ignored the problem that > >> it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx > >> with no way for that to be provided. > > > > I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that > > this was approved by the EP93xx maintainers. > > As the less active of the two EP93xx maintainers I didn't agree to this. > I don't know if Hartley did, but I can't find anything from him in a > quick search of the list. I have Cc'ed him. See http://article.gmane.org/gmane.linux.ports.arm.kernel/124151 Granted, while he agreed to the removal of the zreladdr definitions, reading this again he didn't _explicitly_ agree to the disabling of ZBOOT_ROM. I didn't mention it either, so let's put that on a miscommunication on my part. > I don't have time to follow this issue in depth, but from my vague > understanding ZBOOT_ROM is unlikely to be used on EP93xx, but still > _possible_ to use. Therefore we should not be removing support for > ZBOOT_ROM on EP93xx in case there are some users out there. No worry, I've now excluded EP93xx from my series. My intention never was to permanently remove ZBOOT_ROM support. But because of the EP93xx memory peculiarities, it will have to wait until the ZBOOT_ROM config is moved away from zreladdr. That means you won't be able to have a single zImage for all the EP93xx boards with different memory banks just yet. Nicolas
On Tue, Oct 11, 2011 at 09:25:19PM +0200, Arnd Bergmann wrote: > On Tuesday 11 October 2011 19:48:21 Will Deacon wrote: > > On Tue, Oct 11, 2011 at 04:09:15PM +0100, Will Deacon wrote: > > > For the cpu-mapping, I depend on: > > > > > > ARM: 7011/1: Add ARM cpu topology definition > > > ARM: 7060/1: smp: populate logical CPU mapping during boot > > > ARM: 7061/1: gic: convert logical CPU numbers into physical numbers > > > > > > which I can only see in Russell's for-next branch. > > > > > > For the debug-ll stuff, I depend on: > > > > > > ARM: 7072/1: debug: use kconfig choice for selecting DEBUG_LL UART > > > > > > and conflict with: > > > > > > ARM: 7097/1: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice > > > ARM: 7096/1: debug: Add UART1 config choices > > > ARM: 7116/1: debug: provide dummy default option for DEBUG_LL UART choice > > > ARM: 7073/1: debug: augment DEBUG_LL Kconfig help to clarify behaviour > > > > I've stuck a debug-ll branch and a cpu-mapping branch here: > > > > git://github.com/wdeacon/linux-wd.git > > Ok, thanks. > > > (I finally gave up with my old broken git server!) > > > > These branches are based against -rc9 and I've cherry-picked the > > dependencies from Russell's for-next branch. I'm not sure that's good for > > anything, but it at least helps to show what's already in Russell's tree > > and what's currently outstanding. > > I've stuck them into the arm-soc tree for now, so we get linux-next > coverage, but I won't send them to Linus this way because then we > would get the same commits twice in the history. > > Russell, would be mind putting the 8 patches that Will listed above > into the devel-stable or some other non-rebasing branch so we can > rebase Will's patches on top of that? > > Alternatively, if you prefer you could also throw them out of your > tree so I can send them to Linus, or you could pull the two patch > series from Will into your arm tree so I can drop them completely. It's not that simple as there are some commits in my tree which also depend on the commits which Will mentions. The only thing I can do to keep stuff independent is to rebuild the 'misc' branch into a pair of proper topic branches (debug and smp) and push those out (done). Note that these are based on the same commit as the original 'misc' branch so that I can verify that what we ultimately end up with after the topic merges is identical to what we had before (it is.)
On Mon, Oct 17, 2011 at 09:25:06AM +0100, Russell King - ARM Linux wrote: > The only thing I can do to keep stuff independent is to rebuild the > 'misc' branch into a pair of proper topic branches (debug and smp) > and push those out (done). > > Note that these are based on the same commit as the original 'misc' > branch so that I can verify that what we ultimately end up with > after the topic merges is identical to what we had before (it is.) Thanks for doing this Russell. Arnd, I've made two new branches based on the above at: git://github.com/wdeacon/linux-wd.git cpu-mapping-for-arnd git://github.com/wdeacon/linux-wd.git debug-ll-for-arnd Will
On Monday 17 October 2011, Will Deacon wrote: > On Mon, Oct 17, 2011 at 09:25:06AM +0100, Russell King - ARM Linux wrote: > > The only thing I can do to keep stuff independent is to rebuild the > > 'misc' branch into a pair of proper topic branches (debug and smp) > > and push those out (done). > > > > Note that these are based on the same commit as the original 'misc' > > branch so that I can verify that what we ultimately end up with > > after the topic merges is identical to what we had before (it is.) > > Thanks for doing this Russell. Arnd, I've made two new branches based on the > above at: > > git://github.com/wdeacon/linux-wd.git cpu-mapping-for-arnd > > git://github.com/wdeacon/linux-wd.git debug-ll-for-arnd Ok, thanks a lot. I've updated my branches now and recreated the for-next branch with these. Can you have a look to make sure that everything looks good there now? Arnd
Hi Arnd, On Thu, Oct 20, 2011 at 03:57:49PM +0100, Arnd Bergmann wrote: > Ok, thanks a lot. I've updated my branches now and recreated > the for-next branch with these. Can you have a look to make sure > that everything looks good there now? The cpu mapping and debug-ll stuff all looks good to me, thanks. On the downside, I'm seeing a couple of problems with your for-next branch: 1. I can't compile if !CONFIG_OF, because l2x0_init isn't declared in cache-l2x0.h. There seems to be some broken ifdeffery because of what looks like duplicate commits d94527dd and 5260f15b, although they are slightly different (and actually, both look broken to me anyway!). 2. The GIC is hosed on versatile express. Reverting e3f14d3 ("ARM: gic: add OF based initialization") and 2071a2a4 ("ARM: gic: add irq_domain support") allows me to boot again. Cheers, Will
On 10/21/2011 05:59 AM, Will Deacon wrote: > Hi Arnd, > > On Thu, Oct 20, 2011 at 03:57:49PM +0100, Arnd Bergmann wrote: >> Ok, thanks a lot. I've updated my branches now and recreated >> the for-next branch with these. Can you have a look to make sure >> that everything looks good there now? > > The cpu mapping and debug-ll stuff all looks good to me, thanks. On the > downside, I'm seeing a couple of problems with your for-next branch: > > 1. I can't compile if !CONFIG_OF, because l2x0_init isn't declared in > cache-l2x0.h. There seems to be some broken ifdeffery because of > what looks like duplicate commits d94527dd and 5260f15b, although > they are slightly different (and actually, both look broken to me > anyway!). > This was caught in linux-next. > 2. The GIC is hosed on versatile express. Reverting e3f14d3 ("ARM: gic: add > OF based initialization") and 2071a2a4 ("ARM: gic: add irq_domain support") > allows me to boot again. > I'll take a look at it today. Do you have more details or a boot log? Rob
On Friday 21 October 2011, Rob Herring wrote: > On 10/21/2011 05:59 AM, Will Deacon wrote: > > Hi Arnd, > > > > On Thu, Oct 20, 2011 at 03:57:49PM +0100, Arnd Bergmann wrote: > >> Ok, thanks a lot. I've updated my branches now and recreated > >> the for-next branch with these. Can you have a look to make sure > >> that everything looks good there now? > > > > The cpu mapping and debug-ll stuff all looks good to me, thanks. On the > > downside, I'm seeing a couple of problems with your for-next branch: > > > > 1. I can't compile if !CONFIG_OF, because l2x0_init isn't declared in > > cache-l2x0.h. There seems to be some broken ifdeffery because of > > what looks like duplicate commits d94527dd and 5260f15b, although > > they are slightly different (and actually, both look broken to me > > anyway!). > > > > This was caught in linux-next. It was my fault, but I think it works now. > > 2. The GIC is hosed on versatile express. Reverting e3f14d3 ("ARM: gic: add > > OF based initialization") and 2071a2a4 ("ARM: gic: add irq_domain support") > > allows me to boot again. > > > > I'll take a look at it today. Do you have more details or a boot log? I hope you find this, otherwise I'll have to take the next/soc branch out of for-next in the meantime to avoid the regressions. Thanks for looking into it! Arnd
Hi Rob, On Fri, Oct 21, 2011 at 03:48:24PM +0100, Rob Herring wrote: > On 10/21/2011 05:59 AM, Will Deacon wrote: > > 2. The GIC is hosed on versatile express. Reverting e3f14d3 ("ARM: gic: add > > OF based initialization") and 2071a2a4 ("ARM: gic: add irq_domain support") > > allows me to boot again. > > > > I'll take a look at it today. Do you have more details or a boot log? I'm afraid I'm frantically trying to get things sorted for Prague, so I haven't had a chance to dig further on this. Here's the boot log: Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.1.0-rc9+ (will@mudshark) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #2 SMP PREEMPT Fri Oct 21 10:55:23 BST 2011 [ 0.000000] CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c5387f [ 0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: ARM-Versatile Express [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: ECC disabled, Data cache writealloc [ 0.000000] On node 0 totalpages: 262144 [ 0.000000] free_area_init_node: node 0, pgdat c04035e0, node_mem_map c0421000 [ 0.000000] Normal zone: 1728 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 194880 pages, LIFO batch:31 [ 0.000000] HighMem zone: 576 pages used for memmap [ 0.000000] HighMem zone: 64960 pages, LIFO batch:15 [ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [ 0.000000] PERCPU: Embedded 7 pages/cpu @c0d29000 s5664 r8192 d14816 u32768 [ 0.000000] pcpu-alloc: s5664 r8192 d14816 u32768 alloc=8*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 259840 [ 0.000000] Kernel command line: root=/dev/nfs ip=dhcp console=ttyAMA0 nfsroot=10.1.79.58:/exports/linaro-11.09,tcp rw debug user_debug=31 earlyprintk mem=1G [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 1024MB = 1024MB total [ 0.000000] Memory: 1034180k/1034180k available, 14396k reserved, 262144K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xf8000000 ( 120 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc03c2250 (3817 kB) [ 0.000000] .init : 0xc03c3000 - 0xc03e7620 ( 146 kB) [ 0.000000] .data : 0xc03e8000 - 0xc04040e0 ( 113 kB) [ 0.000000] .bss : 0xc0404104 - 0xc04205f4 ( 114 kB) [ 0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] NR_IRQS:128 nr_irqs:128 128 [ 0.000000] Console: colour dummy device 80x30 [ 0.697227] Calibrating delay loop... <hangs forever> It doesn't seem to be affected by CONFIG_OF, so that rules out one of the patches that I reverted. Will
On 10/21/2011 01:03 PM, Rob Herring wrote: > On 10/21/2011 10:15 AM, Will Deacon wrote: >> Hi Rob, >> >> On Fri, Oct 21, 2011 at 03:48:24PM +0100, Rob Herring wrote: >>> On 10/21/2011 05:59 AM, Will Deacon wrote: >>>> 2. The GIC is hosed on versatile express. Reverting e3f14d3 ("ARM: gic: add >>>> OF based initialization") and 2071a2a4 ("ARM: gic: add irq_domain support") >>>> allows me to boot again. [snip] >> [ 0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 >> [ 0.000000] Preemptible hierarchical RCU implementation. >> [ 0.000000] NR_IRQS:128 nr_irqs:128 128 > > It is working for me. You're booting with sparse irq. ARM's support of > sparse irq is essentially broken. It does not sparsely allocate > irq_descs, but allocates all nr_irqs irq_descs. > > The following patch fixes things and is more in line with other arch's > implementations of arch_probe_nr_irqs. I need to fix mnp platforms > still. Any platform that enables sparse irq needs to either set > machine_desc->nr_irqs or properly call irq_alloc_descs. > > Rob > > From: Rob Herring <rob.herring@calxeda.com> > Date: Tue, 13 Sep 2011 15:08:37 -0500 > Subject: [PATCH] ARM: fix sparse irq pre-allocations > > Returning NR_IRQS in arch_probe_nr_irqs makes SPARSE_IRQ behave the same as > !SPARSE_IRQ in that NR_IRQ irqdescs are allocated. There is some advantage > that NR_IRQ is run-time vs. compile time, but sparse irq is crippled on > ARM. With irqdomains, each interrupt controller should allocate the > irqdescs that it needs. > > If machine_desc->nr_irqs is set, then the irqdescs will be pre-allocated. > If the default NR_IRQS is used then no irqdescs will be pre-allocated. > > Perhaps 0-16 should be reserved for IPIs on SMP? > > There are 3 users of SPARSE_IRQ: pxa, mnp, and shmobile. shmobile is the > only platform that correctly allocates irqdescs. This commit will break > mnp platforms which don't set nr_irqs. > > Signed-off-by: Rob Herring <rob.herring@calxeda.com> > --- > arch/arm/kernel/irq.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c > index de3dcab..b32f438 100644 > --- a/arch/arm/kernel/irq.c > +++ b/arch/arm/kernel/irq.c > @@ -133,8 +133,11 @@ void __init init_IRQ(void) > #ifdef CONFIG_SPARSE_IRQ > int __init arch_probe_nr_irqs(void) > { > - nr_irqs = machine_desc->nr_irqs ? machine_desc->nr_irqs : NR_IRQS; > - return nr_irqs; > + if (machine_desc->nr_irqs) { > + nr_irqs = machine_desc->nr_irqs; > + return nr_irqs; > + } > + return 0; > } > #endif > While I think this is the right fix, this will break platforms which don't set nr_irqs or have a mixture of irq_chips with and without explicit irq_desc allocations (and SPARSE_IRQ on). There is a more simple fix I'm working on to set machine_desc->nr_irqs to NR_IRQ_LEGACY on all machines with a gic. Rob
Hi Arnd, Please pull these DEBUG_LL platform updates for 3.2. You can find the core updates (actually all resident in arch/arm/Kconfig.debug) in Russell's for-next branch. I think Stephen Boyd was planning to move MSM to the new code as well, but I've not seen any code yet so I guess that can go in later. Thanks! Will The following changes since commit 589593ec8b1790c0d9ea227a3811f819eff4f977: Stephen Boyd (1): ARM: 7097/1: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice are available in the git repository at: git://linux-arm.org/linux-2.6-wd.git for-arnd Shawn Guo (1): arm/imx: use Kconfig choice for low-level debug UART selection Will Deacon (2): ARM: plat-samsung: use Kconfig choice for debug UART selection ARM: realview: use Kconfig choice for debug UART selection arch/arm/Kconfig.debug | 117 ++++++++++++++++++-- arch/arm/mach-mxs/include/mach/debug-macro.S | 12 +-- arch/arm/mach-realview/include/mach/debug-macro.S | 17 +--- arch/arm/plat-mxc/include/mach/debug-macro.S | 38 +------ arch/arm/plat-samsung/Kconfig | 7 ++ 5 files changed, 122 insertions(+), 69 deletions(-)