Re: [PATCH 00/16] Omap2 patches for post 2.6.26

Re: [PATCH 00/16] Omap2 patches for post 2.6.26

[Russell King - ARM Linux]

On Fri, Jun 06, 2008 at 06:47:41PM -0700, Tony Lindgren wrote:
> This patch series contains various omap2 patchs from linux-omap tree.
> Big chunk of the patches still improve the clock code. Also more
> clean-up to allow compiling omap2 and omap3 support into the same
> kernel. The patch also adds core omap3430 support, but no board
> files or PM at at this point.

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 ?

Re: [PATCH 00/16] Omap2 patches for post 2.6.26

[Tony Lindgren]

Hi,

* Russell King - ARM Linux <linux@arm.linux.org.uk> [080820 00:23]:
> On Fri, Jun 06, 2008 at 06:47:41PM -0700, Tony Lindgren wrote:
> > This patch series contains various omap2 patchs from linux-omap tree.
> > Big chunk of the patches still improve the clock code. Also more
> > clean-up to allow compiling omap2 and omap3 support into the same
> > kernel. The patch also adds core omap3430 support, but no board
> > files or PM at at this point.
> 
> 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.

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.

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

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

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

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.

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

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

git-pull-request for omap2-upstream branch for next merge window (Was: [PATCH 00/16] Omap2 patches for post 2.6.26)

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [080820 00:23]:
> Hi,
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [080820 00:23]:
> > On Fri, Jun 06, 2008 at 06:47:41PM -0700, Tony Lindgren wrote:
> > > This patch series contains various omap2 patchs from linux-omap tree.
> > > Big chunk of the patches still improve the clock code. Also more
> > > clean-up to allow compiling omap2 and omap3 support into the same
> > > kernel. The patch also adds core omap3430 support, but no board
> > > files or PM at at this point.
> > 
> > Apart from the comments I've made, the rest seem "fine" as far as I can
> > tell.

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

Re: git-pull-request for omap2-upstream branch for next merge window (Was: [PATCH 00/16] Omap2 patches for post 2.6.26)

[Russell King - ARM Linux]

On Sat, Aug 23, 2008 at 04:37:12PM -0700, Tony Lindgren wrote:
> 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

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.

Re: git-pull-request for omap2-upstream branch for next merge window (Was: [PATCH 00/16] Omap2 patches for post 2.6.26)

[Nicolas Pitre]

On Tue, 26 Aug 2008, Russell King - ARM Linux wrote:

> 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

Re: git-pull-request for omap2-upstream branch for next merge window (Was: [PATCH 00/16] Omap2 patches for post 2.6.26)

[Russell King - ARM Linux]

On Tue, Aug 26, 2008 at 12:01:33PM -0400, Nicolas Pitre wrote:
> On Tue, 26 Aug 2008, Russell King - ARM Linux wrote:
> 
> > 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.

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

Re: git-pull-request for omap2-upstream branch for next merge window (Was: [PATCH 00/16] Omap2 patches for post 2.6.26)

[Nicolas Pitre]

On Tue, 26 Aug 2008, Russell King - ARM Linux wrote:

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

And I greatly appreciate your doing so.

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

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.

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

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

Re: git-pull-request for omap2-upstream branch for next merge window (Was: [PATCH 00/16] Omap2 patches for post 2.6.26)

[Nicolas Pitre]

On Tue, 26 Aug 2008, Nicolas Pitre wrote:

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

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

Re: git-pull-request for omap2-upstream branch for next merge window (Was: [PATCH 00/16] Omap2 patches for post 2.6.26)

[Russell King - ARM Linux]

On Tue, Aug 26, 2008 at 02:28:14PM -0400, Nicolas Pitre wrote:
> On Tue, 26 Aug 2008, Nicolas Pitre wrote:
> 
> > 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.
> 
> 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.

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?  ;)

Re: git-pull-request for omap2-upstream branch for next merge window (Was: [PATCH 00/16] Omap2 patches for post 2.6.26)

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [080826 11:50]:
> On Tue, Aug 26, 2008 at 02:28:14PM -0400, Nicolas Pitre wrote:
> > On Tue, 26 Aug 2008, Nicolas Pitre wrote:
> > 
> > > 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.
> > 
> > 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.
> 
> 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