* David Brownell <david-b@xxxxxxxxxxx> [081205 15:36]:
> On Thursday 04 December 2008, Tony Lindgren wrote:
> > > 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.
>
> Or even just getting their goodness into the linux-omap tree,
> as a first step towards getting upstream.
>
> I used the OMAP3 NAND stuff as an example, since we saw a few
> (unmergeable) patches but then everything seemed to fizzle.
Well if somebody does a nand branch against the mainline tree
that we can automerge to l-o tree on daily basis, sure :)
> > Sure the other people can also
> > produce patches against the mainline and linux-omap kernel out
> > of the zoom tree.
>
> That would require people to track the ZOOM kernels, as well
> as mainline and linux-omap (and their own patch queues).
> Not too realistic.
Yeah well drivers are easier as they should be just patches
against the mainline 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.
>
> Yes. And in the case of stuff like NAND, where there's a ZOOM
> driver and a Linux-OMAP driver but nothing in mainline, I suggest
> syncing those two *before* pushing to mainline ... though there
> may well be a case for involving the relevant mainline team at
> that point too, or ignoring one driver.
Sure.
> > - 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.
>
> Yep, that's straightforward. By "core" I presume you mean
> arch/arm/plat-omap or maybe mach-omap{1,2}.
Yup.
> > 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.
>
> That sounds like an interesting plan. It'll cause some level
> of disruption ... which we probably need to have, since without
> it folk seem to have little incentive to track mainline.
>
> A slightly different spin: treat every divergence from mainline
> as a bug that needs fixing. Those branches should mostly have
> fairly short lifespans...
Yeah, and they should be against the mainline tree so they're
ready for merging when the time is right.
> > 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.
>
> Sounds like a plan. Let's see how different the OMAP tree is
> from mainline at that point, and see what the branches will be.
Sounds like clocks and pm branches, then maybe usb, nand, alsa
as needed. And dspgateway branch and dspbridge branch. And then
maybe also twl4030 branch, hehe :)
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
