[GIT PULL] omap changes for v2.6.39 merge window

[David Brown]

On Thu, Mar 31 2011, Nicolas Pitre wrote:

> Leaf nodes on ARM are people coming from corporate background with the 
> old school software development methodologies.  They do it as a _job_ 
> first and foremost.  They only work on Linux because that's what their 
> boss assigned them to. Don't get me wrong: that doesn't mean they are 
> bad people.  Simply that they are not into it for the public recognition 
> (or flaming) from their peers.  Once their code works they lose interest 
> and move on.  That mindset is extremely hard to change and take time, on 
> a scale of years.  Much more time than required to produce the code 
> needed to support that new SOC out of the pipeline.  There are notable 
> exceptions obviously.  But this is still a scalability problem in 
> itself.  So we need men-in-the-middle attacks.

An additional mindset that is difficult to work with in this environment
is that the corporate development methodology has a focus on schedules
and deliverables.  Even people who would otherwise like to contribute
will have pressure to get something done.  Many think of "submit to
mainline" is kind of a last step in a development process, instead of
even a goal to accomplish.

When we push back, there is a good chance they just won't bother, not
because they don't want to do it, but because it doesn't fit a schedule,
and there is already something else for them to work on.

So what's the right answer here.  Practically, someone just sent out a
fairly complete DMA driver for a new MSM device.  Naturally, this
hardware is nothing like anyone else's DMA, but the driver itself pretty
much independent from other kernel APIs.  It isn't even similar to the
existing DMA driver in the MSM.  With it are patches to ifdef-up various
drivers to use the appropriate DMA.

The DMA code, by itself, seems reasonably well written (with some
cleanup and such needed), but it makes everything that uses it messy.
In this particular case, DMA engine will probably need some work to
either incorporate the unique capabilities of this hardware, or at least
allow them to be used.  The author probably won't be able to do this on
their own.

I could pull the driver into the tree, and now we have yet another
driver with yet another API.  If I push back, realistically, it will
probably end up out-of-tree, along with everything that depends on it.

Up until now, it seems that attitude has been that it is better to be
in-tree than out of tree, but are we getting too much stuff to continue
that?

Today, most of the MSM code lives out of tree.  The QuIC tree for MSM
(currently based off of 2.6.35):

  git diff --stat v2.6.35..HEAD | tail -1
   3432 files changed, 1144473 insertions(+), 17315 deletions(-)
  git diff --stat v2.6.35..HEAD arch/arm/mach-msm | tail -1
   595 files changed, 286054 insertions(+), 1928 deletions(-)

There's a large amount of work just to get the code up to kernel
standards (the coding style has been fairly well enforced), and there is
constant development for new hardware.

Thanks,
David Brown

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.