Omap2 patches for post 2.6.26

Apart from the comments I've made, the rest seem "fine" as far as I can tell.

There's a _lot_ of churn in there, some of which is caused there not being sufficient review of the OMAP code before it was merged into mainline. Such things as:

	if (unlikely((u32)clk->parent))

stick out like a sore thumb. And that's a direct result of me getting to the point of "tonnes more omap churn, sod it, I'm just going to apply this."

If the (considerable) upstream workload is going to be reduced to an acceptable level, people further downstream need to take on board that they have a certain element of responsibility with their patches to ensure that they are acceptable _before_ they hit any of these git trees.

That also means sometimes combining two or more patches before it goes upstream - in other words, what's visible to mainline is the "finished product" of development of a new feature _without_ all the historical baggage associated with it.

That said, I'll probably guess that you are completely overloaded by the amount of work coming out of the OMAP trees themselves and can't keep up with it either, so you're probably doing the best you can. I can well believe that now that I have visibility of how the various OMAP trees are structured.

Eg, I don't think you have any way to apply any pressure to downstream people to encourage them to only submit tested patches - because the "downstream people" is just another tree ?

Hi,

Agreed, and I've tried to change this slowly by requiring core omap patches going into linux-omap would be of "mainline quality" to start with.

But unfortunately it's not happening very fast.

Currently people crank out patches that solve one particular problem in a non-generic and non-maintainable way.

This basically causes the situation you're describing. When people do not take proper responsibility of their patches, it unfairly dumps the responsibility of fixing and cleaning up the code to the community in order to be able to use the code. I guess "developing code for hardware by abusing the community" would be pretty close way of describing the current situation.

I agree. I'm actually already collapsing quite a few add-fix cycles into one patch.

Heh yeah that's true :) In general the situation is better now than earlier though with more support from various companies. But it's improving slowly.

The best way to create this pressure is to merge megeable stuff from linux-omap tree to the mainline kernel throw out the rest as patches and just let them rot somewhere.

For core omap code, this is maybe one or two merge cycles away, then one more merge cycle for missing board-*.c files.

This will in effect turn the linux-omap tree into a queue of acceptable patches to the mainline kernel instead of being a repo for half-baked hacks.

So to summarize, everybody, _you_ must be responsible for the quality of _your_ own patches. That's the only way to distribute the work load.

Regards,

Tony

<snip>

Here's the pull request for you assuming your don't have other comments.

I'll be out of town next week, so if there are other comments I won't be able to refresh the patches until I get back.

Regards,

Tony

The following changes since commit dcac5512382d8df4476ce2e9c13e9540b3801d32:
Russell King (1):

        Merge branch 'omap2-clock' of git://git.kernel.org/.../tmlind/linux-omap-2.6.git

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap2-upstream

Jouni Hogander (1):
ARM: OMAP2 Provide function to enable/disable uart clocks

Kevin Hilman (1):
ARM: OMAP2: Implement CPUfreq frequency table based on PRCM table

Paul Walmsley (6):
ARM: OMAP2: Add non-CORE DPLL rate set code and M,N programming
ARM: OMAP: Fix sparse, checkpatch warnings in OMAP2/3 PRCM/PM code
ARM: OMAP2: Move sys_clkout2 clk to core_clkdm
ARM: OMAP2: Add missing SSI L4 interface clock
ARM: OMAP2: Fix sparse, checkpatch warnings fro GPMC code
ARM: OMAP2: Fix sparse, checkpatch warnings in OMAP2/3 IRQ code

Syed Mohammed Khasim (1):
ARM: OMAP2: Add minimal omap3430 support

Tony Lindgren (5):
ARM: OMAP2: Move sleep.S into sleep24xx.S
ARM: OMAP2: Remove OMAP_PRM_REGADDR
ARM: OMAP2: Remove OMAP_CM_REGADDR
ARM: OMAP2: Use omap_globals for CPU detection for multi-omap
ARM: OMAP2: Misc updates from linux-omap tree

Vikram Pandita (1):
ARM: OMAP2: Add pinmux support for omap34xx

 arch/arm/mach-omap1/devices.c                   |    2 +-
 arch/arm/mach-omap2/Kconfig                     |   12 +-
 arch/arm/mach-omap2/Makefile                    |    6 +-
 arch/arm/mach-omap2/clock.c                     |  124 ++++----
 arch/arm/mach-omap2/clock.h                     |    3 +-
 arch/arm/mach-omap2/clock24xx.c                 |  148 ++++++--
 arch/arm/mach-omap2/clock24xx.h                 |  335 ++++++++++--------
 arch/arm/mach-omap2/clock34xx.c                 |  141 ++++++++-
 arch/arm/mach-omap2/clock34xx.h                 |  431 ++++++++++++-----------
 arch/arm/mach-omap2/cm-regbits-34xx.h           |    7 +
 arch/arm/mach-omap2/cm.h                        |   17 +-
 arch/arm/mach-omap2/devices.c                   |  229 ++++++++++--
 arch/arm/mach-omap2/gpmc.c                      |   70 +++--
 arch/arm/mach-omap2/id.c                        |   67 +++-
 arch/arm/mach-omap2/io.c                        |  147 ++++++--
 arch/arm/mach-omap2/irq.c                       |   66 ++--
 arch/arm/mach-omap2/memory.c                    |    3 +-
 arch/arm/mach-omap2/memory.h                    |    7 +
 arch/arm/mach-omap2/mux.c                       |  186 ++++++++++-
 arch/arm/mach-omap2/pm.c                        |    4 +-
 arch/arm/mach-omap2/prm-regbits-34xx.h          |    9 +
 arch/arm/mach-omap2/prm.h                       |  166 ++++-----
 arch/arm/mach-omap2/serial.c                    |  112 +++----
 arch/arm/mach-omap2/{sleep.S => sleep24xx.S}    |   32 +-
 arch/arm/mach-omap2/sram242x.S                  |    5 +
 arch/arm/mach-omap2/sram243x.S                  |    5 +
 arch/arm/plat-omap/Kconfig                      |    9 +-
 arch/arm/plat-omap/common.c                     |    5 +
 arch/arm/plat-omap/cpu-omap.c                   |   57 +++-
 arch/arm/plat-omap/devices.c                    |  116 +++++--
 arch/arm/plat-omap/include/mach/board-2430sdp.h |    6 +-
 arch/arm/plat-omap/include/mach/board-apollon.h |    6 +
 arch/arm/plat-omap/include/mach/board-h4.h      |    5 +-
 arch/arm/plat-omap/include/mach/board.h         |    2 +
 arch/arm/plat-omap/include/mach/clock.h         |   11 +-
 arch/arm/plat-omap/include/mach/common.h        |    8 +
 arch/arm/plat-omap/include/mach/control.h       |   17 +-
 arch/arm/plat-omap/include/mach/cpu.h           |    5 +
 arch/arm/plat-omap/include/mach/debug-macro.S   |   12 +
 arch/arm/plat-omap/include/mach/entry-macro.S   |   12 +-
 arch/arm/plat-omap/include/mach/gpio.h          |    2 +
 arch/arm/plat-omap/include/mach/gpmc.h          |    7 +
 arch/arm/plat-omap/include/mach/hardware.h      |    2 +-
 arch/arm/plat-omap/include/mach/io.h            |   57 +++
 arch/arm/plat-omap/include/mach/irqs.h          |   71 ++++
 arch/arm/plat-omap/include/mach/mcbsp.h         |    2 +-
 arch/arm/plat-omap/include/mach/memory.h        |    2 +-
 arch/arm/plat-omap/include/mach/mmc.h           |    4 +
 arch/arm/plat-omap/include/mach/mux.h           |  147 +++++++-
 arch/arm/plat-omap/include/mach/omap1510.h      |    2 +
 arch/arm/plat-omap/include/mach/omap16xx.h      |    7 +-
 arch/arm/plat-omap/include/mach/omap24xx.h      |    2 +-
 arch/arm/plat-omap/include/mach/omapfb.h        |    3 +
 arch/arm/plat-omap/include/mach/pm.h            |    3 +-
 arch/arm/plat-omap/include/mach/powerdomain.h   |    1 +
 arch/arm/plat-omap/include/mach/prcm.h          |    5 +-
 arch/arm/plat-omap/include/mach/sdrc.h          |    2 +
 arch/arm/plat-omap/include/mach/serial.h        |    6 +
 arch/arm/plat-omap/include/mach/system.h        |    6 +-
 59 files changed, 2071 insertions(+), 865 deletions(-)
 rename arch/arm/mach-omap2/{sleep.S => sleep24xx.S} (85%)

This is why I don't want to publish my git tree. You're the second person to base their tree off my devel branch.

The devel branch is _constantly_ remerged. Basing your tree on it will mean I can't merge it. Please don't. Base it either on something in Linus' tree _or_ something you've already asked me to pull.

If this continues, I'll go back to only publishing my git tree in diff and mbox form.

What's the advantage of screwing everybody only because few individuals don't get it right?

It is easy enough to back out a bad pull with git. If you're tired of flaming people, simply ask that any git pull request message also contains the information about the commit it is based on so that you can ignore bad pulls up front.

Nicolas

Like I just have done.

The point is that my git usage does _not_ match with the requirements brought on by publishing the git tree, and therefore it should _not_ be published in the first place. The only reason it is published is because people like you vocally demand it to be so. It's not my choice.

That requirement is that once a commit has been published, it becomes immutable. That requirement is there so that people _can_ work off your published tree. If you're not sure of the work you have in your git tree, you shouldn't be publishing those commits.

However, that's just not true of the way I manage my tree.

It's only going to be a matter of time before there's another chorus of people demanding that I yet again change the way I work, demanding that I conform...

And I greatly appreciate your doing so.

That's not all black or white. Many people have branches which are rebased all the time, especially when those branches are made up of other evolving branches. I Think this is the case of your devel branch which sounds pretty fine to me. As long as the volatile nature of such branch is clearly advertised and people are told not to base their own work on of course, and I think you did so many times now.

Especially with a git tree containing multiple branches, one must be wise enough not to pick one at random and use that to commit stuff on top. This is where the tool, as good as it may be, still isn't a replacement for proper communication. When in doubt, people should just ask.

What is discouraged though, is the republishing of stuff that you were asked to pull and that you rebased locally. If other people's stuff have to be rebased for whatever reason then it is best to simply drop that stuff and ask the originator to rebase it and then repull.

I don't think you have to change the way you work now, and IMHO you already conform to the git usage of the majority of Linux maintainers.

Nicolas

And I've just seen the commit message of the top commit in the devel branch. :-) If that is not effective then I don't know what might be.

Nicolas

Well, the theory is that it'll appear in any pull requests generated by git-request-pull, and of course everyone reads the output of that command before they mail it, don't they? ;)

Heh, I'll rebase on top of the earlier pull.

Tony