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