Re: [PATCH OMAPZOOM] OMAP: DMA: Fix CCR programming for request line > 63

[Tony Lindgren <tony@atomide.com>]

* twebb <taliaferro62@gmail.com> [090108 16:08]:
> >
> > Well l-o tree is short for the linux-omap tree. Then I have various
> > queues of stuff going into the mainline kernel:
> >
> > omap-fixes
> > omap-upstream
> > omap1-upstream
> > omap2-upstream
> > omap3-upstream
> > ...
> >
> > Out of these queues omap-fixes will be sent out as needed during the
> > -rc cycle, while omap*-upstream queues are stuff for the next merge
> > window.
> >
> > These branches show up at the git web interface at the bottom:
> >
> > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary
> >
> > Not that many patches in these queues right now, btw.
> >
> 
> That's very helpful.  Would you mind confirming/answering a few more questions?
> 
> 1.  Generally, are all fixes/changes that go to any of the queues
> headed to the mainline always pushed into the l-o tree?  If not, why
> not?

If something is updated with the patches going into the mainline, they
may not get updated in the l-o tree until the changes fall down during
the next merge with mainline.

> 2.  How about the reverse - are all l-o fixes/changes eventually
> queued to mainline?  Or is there certain l-o functionality that won't
> ever go to mainline?

Only the ones that apply and are ready to go. Ideally we would just
have everything in sync with the mainline tree so everything in l-o
tree would be going to mainline tree. But we still carry around quite
a bit of code that still needs work before submitting to mainline. Some
examples are the clock and PM changes.

> 3.  By "merge window" do you mean times that you pull mainline updates
> down into l-o tree?

Merge window = About two weeks after Linus tags a major release and
before -rc1 is tagged. Since the omap core stuff gets merged via
Russell, we need to have patches going to mainline ready around -rc5
so Russell has enough time to look at them.

Regards,

Tony