* David Brownell <david-b@xxxxxxxxxxx> [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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
