[GIT PULL] ARM MSM updates for 2.6.35-rc1

[GIT PULL] ARM MSM updates for 2.6.35-rc1

[Daniel Walker]

Hi Linus,

Here's a couple of simple patches. One fixes a compile failure in
certain situations, and the other is just dead code removal.

Daniel


The following changes since commit 7b52161d14fa8a22a2387f4aa2fb7b854587830d:

  msm: 7x30 Kconfig and makefile changes (2010-05-13 16:08:55 -0700)

are available in the git repository at:
  git://codeaurora.org/quic/kernel/dwalker/linux-msm.git msm-core

Daniel Walker (1):
      msm: dma: add completion.h header

Huang Weiyi (1):
      arm: msm: remove unused #include <linux/version.h>

 arch/arm/mach-msm/acpuclock-arm11.c |    1 -
 arch/arm/mach-msm/clock.c           |    1 -
 arch/arm/mach-msm/dma.c             |    1 +
 3 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-msm/acpuclock-arm11.c b/arch/arm/mach-msm/acpuclock-arm11.c
index af5e85b..6ca42fd 100644
--- a/arch/arm/mach-msm/acpuclock-arm11.c
+++ b/arch/arm/mach-msm/acpuclock-arm11.c
@@ -17,7 +17,6 @@
  *
  */
 
-#include <linux/version.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/list.h>
diff --git a/arch/arm/mach-msm/clock.c b/arch/arm/mach-msm/clock.c
index 9cb1276..c57210f 100644
--- a/arch/arm/mach-msm/clock.c
+++ b/arch/arm/mach-msm/clock.c
@@ -14,7 +14,6 @@
  *
  */
 
-#include <linux/version.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/module.h>
diff --git a/arch/arm/mach-msm/dma.c b/arch/arm/mach-msm/dma.c
index 3d725ae..3db0bfe 100644
--- a/arch/arm/mach-msm/dma.c
+++ b/arch/arm/mach-msm/dma.c
@@ -17,6 +17,7 @@
 #include <linux/err.h>
 #include <linux/io.h>
 #include <linux/interrupt.h>
+#include <linux/completion.h>
 #include <mach/dma.h>
 
 #define MSM_DMOV_CHANNEL_COUNT 16

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Daniel Walker]

On Thu, 2010-05-27 at 14:52 -0700, Daniel Walker wrote:
> Hi Linus,
> 
> Here's a couple of simple patches. One fixes a compile failure in
> certain situations, and the other is just dead code removal.
> 
> Daniel
> 
> 
> The following changes since commit 7b52161d14fa8a22a2387f4aa2fb7b854587830d:
> 
>   msm: 7x30 Kconfig and makefile changes (2010-05-13 16:08:55 -0700)
> 
> are available in the git repository at:
>   git://codeaurora.org/quic/kernel/dwalker/linux-msm.git msm-core

Don't forget about this one! Or was something wrong with it?

Daniel

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Linus Torvalds]

On Wed, 2 Jun 2010, Daniel Walker wrote:
> 
> Don't forget about this one! Or was something wrong with it?

I got a bit frustrated with ten different ARM pulls per day at one point.

There's something wrong with ARM development. The amount of pure noise in 
the patches is incredibly annoying. Right now, ARM is already (despite me 
not reacting to some of the flood) 55% of all arch/ changes since 2.6.34, 
and it's all pointless churn in 

	arch/arm/configs/
	arch/arm/mach-xyz
	arch/arm/plat-blah

and at a certain point in the merge window I simply could not find it in 
me to care about it any more.

Do you guys at all talk about this problem? Have any of the ARM people 
bothered to look at the arch/arm diffs and see how mind-deadening they 
are? I try to look through these kinds of things when I pull, but after a 
million lines of pure noise, it gets old pretty quickly.

Somehow, I can't believe that you need thousands of lines for each random 
arch/arm/mach-xyz (yeah, some very few of them are smaller).

For a taste of the mind-deadening experience, just do

	for i in arch/arm/mach-*
	do
		echo $i; wc -l $(git ls-files $i)
	done | less -S

and imagine being on the receiving side of that.

			Linus

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Linus Torvalds]

On Wed, 2 Jun 2010, Linus Torvalds wrote:
> 
> I got a bit frustrated with ten different ARM pulls per day at one point.

In other words - when I do a "git pull", I really want to feel like there 
is some point to it. When I get ten different ARM maintainers asking me to 
pull stuff that just looks like noise, I'm just not getting those warm and 
fuzzies about them. 

I'm also getting the feeling that now that different arch sub-architecture 
maintainers all try to get their stuff in through me, things have actually 
gotten worse - there's even less feeling of "somebody is actually trying 
to keep track of all this stuff".

I understand why rmk wasn't happy. I'm also not really happy. 

			Linus

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Daniel Walker]

On Wed, 2010-06-02 at 14:39 -0700, Linus Torvalds wrote:
> 
> On Wed, 2 Jun 2010, Linus Torvalds wrote:
> > 
> > I got a bit frustrated with ten different ARM pulls per day at one point.
> 
> In other words - when I do a "git pull", I really want to feel like there 
> is some point to it. When I get ten different ARM maintainers asking me to 
> pull stuff that just looks like noise, I'm just not getting those warm and 
> fuzzies about them. 
> 
> I'm also getting the feeling that now that different arch sub-architecture 
> maintainers all try to get their stuff in through me, things have actually 
> gotten worse - there's even less feeling of "somebody is actually trying 
> to keep track of all this stuff".
> 
> I understand why rmk wasn't happy. I'm also not really happy. 

Should all us ARM sub-architecture maintainers get together and make a
jumbo pull request with everything merged together?

Like someone, not you or RMK, would take all the sub-architecture
requests and put them into a single pull request w/ lots of details as
to what it all is ..

I know that doesn't solve what you said in the original email, how we
develop. One thing to remember is that we have tons of ARM device to
manage, and lots of chip manufactures .. So ARM is pretty diverse. I'm
not saying we're all perfect however.

Daniel

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Daniel Walker]

On Wed, 2010-06-02 at 14:27 -0700, Linus Torvalds wrote:
> 
> On Wed, 2 Jun 2010, Daniel Walker wrote:
> > 
> > Don't forget about this one! Or was something wrong with it?
> 
> I got a bit frustrated with ten different ARM pulls per day at one point.
> 
> There's something wrong with ARM development. The amount of pure noise in 
> the patches is incredibly annoying. Right now, ARM is already (despite me 
> not reacting to some of the flood) 55% of all arch/ changes since 2.6.34, 
> and it's all pointless churn in 
> 
> 	arch/arm/configs/
> 	arch/arm/mach-xyz
> 	arch/arm/plat-blah
> 
> and at a certain point in the merge window I simply could not find it in 
> me to care about it any more.
> 
> Do you guys at all talk about this problem? Have any of the ARM people 
> bothered to look at the arch/arm diffs and see how mind-deadening they 
> are? I try to look through these kinds of things when I pull, but after a 
> million lines of pure noise, it gets old pretty quickly.

There's room for the sub-architectures to combine stuff. I think there
is work going on to do that (at some level).

> Somehow, I can't believe that you need thousands of lines for each random 
> arch/arm/mach-xyz (yeah, some very few of them are smaller).

I'm not an authority by any means, but every time there is a new device
released (which is often) you get a new file under some mach-xyz
directory, or some large modification to an already existing file. Plus
a config file potentially. It's a little bit like the wild west, and
seems way wilder than x86 every was.

I think from the sub-architecture maintainer perspective the pain is all
hidden behind the Linus curtain , or RMK curtain or the some other
maintainer curtain. So we don't really talk about it that often. I
thought you we're totally happy with the situation ..

If you have some idea's for fixing things, I'm all ears along with my
faithful sub-architecture maintainer brothers.

Daniel

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Kevin Hilman]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, 2 Jun 2010, Daniel Walker wrote:
>> 
>> Don't forget about this one! Or was something wrong with it?
>
> I got a bit frustrated with ten different ARM pulls per day at one point.
>
> There's something wrong with ARM development. The amount of pure noise in 
> the patches is incredibly annoying. Right now, ARM is already (despite me 
> not reacting to some of the flood) 55% of all arch/ changes since 2.6.34, 
> and it's all pointless churn in 
>
> 	arch/arm/configs/
> 	arch/arm/mach-xyz
> 	arch/arm/plat-blah
>
> and at a certain point in the merge window I simply could not find it in 
> me to care about it any more.
>
> Do you guys at all talk about this problem? Have any of the ARM people 
> bothered to look at the arch/arm diffs and see how mind-deadening they 
> are? I try to look through these kinds of things when I pull, but after a 
> million lines of pure noise, it gets old pretty quickly.
>
> Somehow, I can't believe that you need thousands of lines for each random 
> arch/arm/mach-xyz (yeah, some very few of them are smaller).

As one of the sub-arch maintainers (arch/arm/mach-davinci), I can
attempt to answer for some of the churn.

There indeed has been lots of change in mach-davinci, but I wouldn't
consider it noise.  In that one mach directory, I support ~10 SoCs in
the same family and for each SoC there is at least one board
supported.  I'm also a core developer for mach-omap*, and the number
of SoCs/boards supported there is equally large.

Each time we add support for a new SoC in the family some changes are
needed to generalize existing code to work on the existing SoCs as
well as the new ones.  This generalizing is actually reducing the size
of the diff compared to what it would be if it were added using
copy-paste, but I understand why it might look like churn.

I certainly understand why this would be mind-numbing to anyone who
doesn't care about davinci, or ARM-based devices.  Indeed, even other
ARM sub-arches developers don't need to care about most of what is in
my mach dir and would consider it mind-numbing as well.

The fact is that ARM-based devices multiply like rabbits, and there is
a huge amount of diversity between the various derivatives.  Also,
support most of these devices has lived out of tree for a long time.
Now that we have a relatively direct path which doesn't require any
single person to have to understand all the mind-numbing details of
all of these ARM-based platforms, it has allowed us to significantly
improve the support for these devices upstream.  Anything that is
common to all devices still goes through RMK.

Kevin

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Linus Torvalds]

On Wed, 2 Jun 2010, Kevin Hilman wrote:
>
> There indeed has been lots of change in mach-davinci, but I wouldn't
> consider it noise.  In that one mach directory, I support ~10 SoCs in
> the same family and for each SoC there is at least one board
> supported.  I'm also a core developer for mach-omap*, and the number
> of SoCs/boards supported there is equally large.

The problem with this is that it's just not maintainable to keep on adding 
random stuff, especially since I doubt any of it ever gets aged away 
either.

arch/arm as-is is already about 800k lines. Compare that to arch/x86, 
which is less than a third of that. Now, what is the difference?

 - x86 has its drivers elsewhere, and they are _discoverable_ and not 
   hardcoded to some platform. They have often also been useful (to say 
   the least) to other architecture platforms. That's not always true for 
   all of them (we do have drivers/platform/x86, but at least that's 
   maintained separately and is nowhere near the mess that is ARM)

 - in contrast, ARM seems to be a mess. I realize it's largely because the 
   hardware companies are so f*cked up, but guys, we need to have some 
   handle on it too.  I was willing to take the direct merges, and I still 
   am, but I'm willing to do it only if I have a feeling that things are 
   under control. And I'm not getting that feeling.

 - TWO HUNDRED THOUSAND lines of arch/arm is just pure garbage, namely the 
   defconfig files. Quite frankly, anybody who calls that anything but 
   pure "noise" is just misguided and being stupid.

So yes, I do consider a lot of it "noise". When there's two hundred 
thousand lines of garbage, and it keeps growing without bounds, something 
needs to be done. 

Now, I'm actually considering just getting rid of all the 'defconfig' 
files entirely. The x86 model is sane (there's two of them, nobody likely 
uses them), but ARM and POWERPC (and to a lesser config SH and MIPS) have 
turned the whole concept into a disgusting mess. 

But while POWERPC has abused that thing too, in _other_ respects it has 
been much less egregious. 

So I can largely fix the defconfig mess on my own (by just using a simple 
oneliner shell script to deletes them all) but that really only fixes one 
particularly annoying symptom - not the underlying issue. We do need 
somebody to maintain the arm platform mess, and actually tries to get some 
infrastructure or something in place so that it doesn't explode.

> The fact is that ARM-based devices multiply like rabbits, and there is
> a huge amount of diversity between the various derivatives.  Also,
> support most of these devices has lived out of tree for a long time.
> Now that we have a relatively direct path which doesn't require any
> single person to have to understand all the mind-numbing details of
> all of these ARM-based platforms, it has allowed us to significantly
> improve the support for these devices upstream.  Anything that is
> common to all devices still goes through RMK.

The thing is, I bet there is way more commonality still to be taken 
advantage of.  And even if there isn't, we need somebody who cares, and 
doesn't just mindlessly aggregate all the crud. Somebody with the taste to 
say "ok, that's just too effin ugly, you need to fix things up" 
occasionally.

		Linus

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Wed, 2010-06-02 at 18:20 -0700, Linus Torvalds wrote:
> 
> Now, I'm actually considering just getting rid of all the 'defconfig' 
> files entirely. The x86 model is sane (there's two of them, nobody likely 
> uses them), but ARM and POWERPC (and to a lesser config SH and MIPS) have 
> turned the whole concept into a disgusting mess. 

I agree that the defconfig mechanism is broken (ie. carrying the full
text in tree), but the concept is sane IMHO.

What'd be nice is if the defconfig could just be a delta against a base
config for the architecture - that would make most of them reasonably
small, just turning on/off a few options.

You can sort of do that today, by just storing a delta, but oldconfig
will silently turn off things you have enabled if prereqs change, so
that doesn't really work I think.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Linus Torvalds]

On Thu, 3 Jun 2010, Michael Ellerman wrote:
> 
> You can sort of do that today, by just storing a delta, but oldconfig
> will silently turn off things you have enabled if prereqs change, so
> that doesn't really work I think.

I think you can do it today with various hacks. Up to and including 
basically doing something that just selects the options you want.

IOW, you could likely have a human-written Kconfig.<platform> file that 
just does 

	define_bool MYPLATFORM y
		select .. everything I need ..

	include Kconfig.main

or a number of other tricks.

Ingo and the x86 folks (who I really think have done a very good job, and 
there really aren't any crazy defconfig files there) have this "make 
randconfig" together with scripted requirements so that you can actually 
_boot_ the random config, just because the requirements make sure that the 
things needed for booting on the test setup are selected.

I forget exactly what the build setup there is (Ingo described it to me 
long time ago, but since I don't even want to have a build farm in my 
home, I didn't care much).

But we certainly _can_ do a better job than the 'defconfig' thing that was 
really never meant for the kind of use it sees in ARM/POWERPC/SH/MIPS, and 
that really isn't appropriate for any manual editing (so people just run 
"make oldconfig" with tweaking or something, and then use the newly 
generated file).

And I suspect that it really is best to just remove the existing defconfig 
files. People can see them in the history to pick up what the heck they 
did, but no way will any sane model ever look even _remotely_ like them, 
so they really aren't a useful basis for going forward.

But don't worry. It didn't happen this merge window, obviously.

		Linus

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Tony Lindgren]

* Linus Torvalds <torvalds@linux-foundation.org> [100603 07:25]:
> 
> 
> On Thu, 3 Jun 2010, Michael Ellerman wrote:
> > 
> > You can sort of do that today, by just storing a delta, but oldconfig
> > will silently turn off things you have enabled if prereqs change, so
> > that doesn't really work I think.
> 
> I think you can do it today with various hacks. Up to and including 
> basically doing something that just selects the options you want.
> 
> IOW, you could likely have a human-written Kconfig.<platform> file that 
> just does 
> 
> 	define_bool MYPLATFORM y
> 		select .. everything I need ..
> 
> 	include Kconfig.main
> 
> or a number of other tricks.

I agree all the defconfigs are a pain just for the omaps alone.

If this is of any help we could now just keep omap3_defconfig for
arch/arm/mach-omap2 and get rid of 23 config files:

$ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | wc -l
23

It needs some more work for omap2 though to boot to userspace as
there are still some known issues with ARMv6 vs ARMv7 support and
VFP2 vs 3 support. Will try to look at fixing those again when
I have a chance.

Then making the multi-omap thing work on all omap1 boards would
cut down another 15 defconfigs, that should be also doable.

To be able to compile in multiple arm architectures we would have
to get rid of the Makefile.boot files and NR_IRQS and then have
some kind of common clock framework at least.

I did some experiments compiling in both mach-omap1 and mach-omap2
a few years back using ARMv5 flags, there were probably other issues
too like some conflicting defines.

Cheers,

Tony

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Eric Miao]

On 06/03/2010 12:26 PM, Linus Torvalds wrote:
> 
> 
> On Thu, 3 Jun 2010, Michael Ellerman wrote:
>>
>> You can sort of do that today, by just storing a delta, but oldconfig
>> will silently turn off things you have enabled if prereqs change, so
>> that doesn't really work I think.
> 
> I think you can do it today with various hacks. Up to and including 
> basically doing something that just selects the options you want.
> 
> IOW, you could likely have a human-written Kconfig.<platform> file that 
> just does 
> 
> 	define_bool MYPLATFORM y
> 		select .. everything I need ..
> 
> 	include Kconfig.main
> 
> or a number of other tricks.
> 
> Ingo and the x86 folks (who I really think have done a very good job, and 
> there really aren't any crazy defconfig files there) have this "make 
> randconfig" together with scripted requirements so that you can actually 
> _boot_ the random config, just because the requirements make sure that the 
> things needed for booting on the test setup are selected.
> 
> I forget exactly what the build setup there is (Ingo described it to me 
> long time ago, but since I don't even want to have a build farm in my 
> home, I didn't care much).
> 
> But we certainly _can_ do a better job than the 'defconfig' thing that was 
> really never meant for the kind of use it sees in ARM/POWERPC/SH/MIPS, and 
> that really isn't appropriate for any manual editing (so people just run 
> "make oldconfig" with tweaking or something, and then use the newly 
> generated file).
> 

It certainly looks a better way to handle this. However, considering the
facts that there are so many platforms out there, and doing a transition
without breaking any of them is a lot work, it's actually easier to just
reduce the number of defconfig at this moment, provided that most ARM
platforms with the same SoC are able to be built into a single kernel.
There are some exceptions though, I'd suggest not to introduce any other
defconfig for these platforms until their problem is solved.

Russell has setup a thread for this issue in linux-arm-kernel ML, so
hopefully there will be a lot patches around to address it.

There are some specific problems with ARM, e.g. some platforms are really
not maintained for a long time, and even no way to find someone or some
machine to test. And even with one defconfig per SoC, there could still
be about > 60 defconfigs there (compared with 178 at this moment).

> And I suspect that it really is best to just remove the existing defconfig 
> files. People can see them in the history to pick up what the heck they 
> did, but no way will any sane model ever look even _remotely_ like them, 
> so they really aren't a useful basis for going forward.
> 
> But don't worry. It didn't happen this merge window, obviously.
> 
> 		Linus

Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

[Ben Dooks]

On Wed, Jun 02, 2010 at 06:20:09PM -0700, Linus Torvalds wrote:
> 
>    am, but I'm willing to do it only if I have a feeling that things are 
>    under control. And I'm not getting that feeling.
> 
>  - TWO HUNDRED THOUSAND lines of arch/arm is just pure garbage, namely the 
>    defconfig files. Quite frankly, anybody who calls that anything but 
>    pure "noise" is just misguided and being stupid.
> 
> So yes, I do consider a lot of it "noise". When there's two hundred 
> thousand lines of garbage, and it keeps growing without bounds, something 
> needs to be done. 
> 
> Now, I'm actually considering just getting rid of all the 'defconfig' 
> files entirely. The x86 model is sane (there's two of them, nobody likely 
> uses them), but ARM and POWERPC (and to a lesser config SH and MIPS) have 
> turned the whole concept into a disgusting mess. 
> 
> But while POWERPC has abused that thing too, in _other_ respects it has 
> been much less egregious. 

unfortunately there are so many different variants of the ARM
architecture that these defconfigs spring up to ensure that a base
compile for each one of them is performed. We run an autobuild which
runs through all these defconfigs and produces a report of what
happened to allow tracking of build regressions at the moment.
 
> So I can largely fix the defconfig mess on my own (by just using a simple 
> oneliner shell script to deletes them all) but that really only fixes one 
> particularly annoying symptom - not the underlying issue. We do need 
> somebody to maintain the arm platform mess, and actually tries to get some 
> infrastructure or something in place so that it doesn't explode.

Someone should defiently cull the older defconfigs for sepcific
machines, many of which probably don't get built for mainline.
~ 
> > The fact is that ARM-based devices multiply like rabbits, and there is
> > a huge amount of diversity between the various derivatives.  Also,
> > support most of these devices has lived out of tree for a long time.
> > Now that we have a relatively direct path which doesn't require any
> > single person to have to understand all the mind-numbing details of
> > all of these ARM-based platforms, it has allowed us to significantly
> > improve the support for these devices upstream.  Anything that is
> > common to all devices still goes through RMK.
> 
> The thing is, I bet there is way more commonality still to be taken 
> advantage of.  And even if there isn't, we need somebody who cares, and 
> doesn't just mindlessly aggregate all the crud. Somebody with the taste to 
> say "ok, that's just too effin ugly, you need to fix things up" 
> occasionally.

yes, there is that problem, and many of the big company players have
yet to really see the necessity in this... It has taken a while now to
convince the necessary people at Samsung that simply copying and
modifying existing driver/support is simply not going to fly.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'