Re: OMAP Zoom kernel ALSA build problem

[Tony Lindgren <tony@atomide.com>]

* David Brownell <david-b@pacbell.net> [081204 11:03]:
> On Thursday 04 December 2008, Koen Kooi wrote:
> > >>> Perhaps that kernel should sync with newer code?
> >
> >  	The rest  
> > of the beagleboards peeps wants to get things as fast as possible into  
> > mainline instead of wanting awesomely good powermanagement.
> 
> Bull hockey ... they want *BOTH* mainline support and good PM.  :)
> 
> PM support is still cooking.  Support for other OMAP goodness
> can -- and does! -- evolve in parallel.

Paul and RMK are working on getting the omap clock patches into
mainline. After that we can work on getting Kevin's PM branch into
mainline.

> Having a ZOOM fork to help roll goodies out of TI-internal trees
> into mainline is fine -- TI has OMAP hardware for a long time before 
> the chips go public -- but the goal should be to *help* and that means
> both (a) tracking mainline, probably via linux-omap, and (b) pushing
> goodies out of that ZOOM fork so they're more broadly available.

Yes, the upstream feedback seems to be still missing from zoom.

> So for example the NAND acceleration stuff seems to have gone
> nowhere ... while that ZOOM fork may have some updates, they've not
> gotten into the main OMAP tree, or into mainline.

That is frustrating. People at TI _should_ be working on sending
patches from zoom to upstream. Sure the other people can also
produce patches against the mainline and linux-omap kernel out
of the zoom tree.

In general, here's how the patch flow needs to happen:

- All driver patches need to be posted to the right driver mailing
  lists with linux-omap mailing list Cc'd. The patches need need
  to be against the mainline kernel tree. The recent developments
  with the ASoC and the new fb/v4l code is a good example how this
  is working.

- All core omap code needs to be posted to linux-omap for review
  and will then be queued up into going into the mainline tree.
  For any patches that apply already into the mainline kernel,
  the patches need to be against the mainline kernel. For any
  more complex patches, also linux-arm-kernel and maybe LKML lists
  should be Cc'd.

Soonish the linux-omap tree will become just a queue for patches
for the merge windows. So essentially we'll be using the mainline
kernel with some branches automerged hopefully real-soon-now.

I think the right time to make that switch after Paul's clock
patches are integrated into the mainline kernel. Then we'll move
the non-mainline code into their own branches, or just drop it
if nobody wants to maintain it.

In general, people are encouraged to maintain their own branches
for more larger patches, like we already have for pm, clocks,
dspbridge, mmc, i2c. Then I can mirror these branches and automerge
them branches on daily basis.

Cheers,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html