[GIT PULL] DEBUG_LL platform updates for 3.2

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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(-)

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Arnd Bergmann]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Arnd Bergmann]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Shawn Guo]

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. 

-- 
Regards,
Shawn

[GIT PULL] DEBUG_LL platform updates for 3.2

[Arnd Bergmann]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Arnd Bergmann]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Nicolas Pitre]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Arnd Bergmann]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Russell King - ARM Linux]

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.

[GIT PULL] DEBUG_LL platform updates for 3.2

[Nicolas Pitre]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Russell King - ARM Linux]

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).

[GIT PULL] DEBUG_LL platform updates for 3.2

[Nicolas Pitre]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Arnd Bergmann]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Ryan Mallon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Ryan Mallon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Nicolas Pitre]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Jamie Iles]

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.

Jamie

[GIT PULL] DEBUG_LL platform updates for 3.2

[Nicolas Pitre]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Russell King - ARM Linux]

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.

[GIT PULL] DEBUG_LL platform updates for 3.2

[Nicolas Pitre]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Russell King - ARM Linux]

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.

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Russell King - ARM Linux]

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.

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Russell King - ARM Linux]

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.)

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Arnd Bergmann]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Rob Herring]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Arnd Bergmann]

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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Will Deacon]

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 at 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

[GIT PULL] DEBUG_LL platform updates for 3.2

[Rob Herring]

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.
>>>
>>
>> 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 at 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

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

-- 
1.7.5.4

[GIT PULL] DEBUG_LL platform updates for 3.2

[Rob Herring]

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