DRM pull for v5.3-rc1

[Daniel Vetter]

On Mon, Jul 15, 2019 at 5:04 PM Jason Gunthorpe <jgg at mellanox.com> wrote:
>
> On Mon, Jul 15, 2019 at 04:19:26PM +0200, Daniel Vetter wrote:
>
> > > Linus, do you have any advice on how best to handle sharing mm
> > > patches? The hmm.git was mildly painful as it sits between quilt on
> > > the -mm side and what seems like 'a world of interesting git things'
> > > on the DRM side (but maybe I just don't know enough about DRM).
> >
> > I think the approach in this merge window worked fairly well:
> > - refactor/rework core mm stuff in (h)mm.git
> > - handle all the gpu stuff in drm.git
> > - make the clashes workable through some clever prep patches like
> >   we've done this time around
>
> Okay, as long as we agree.
>
> I think part of the challenge with hmm.git was setting some
> expectation for managing conflicts - there is some happy middle ground
> between none & scary we need to navigate to make this work.
>
> > I think Linus wants to be able to look through core mm stuff quite
> > closely, so not a good idea if we deeply intertwin it with one of the
> > biggest subsystems there is.
>
> There is definately a bunch of stuff that is under the mm/ directory
> but is not quite 'core mm' - it would be good if we could rely on
> mailing list review of that part and use a topic workflow to manage
> things. This was/is more or less my plan with hmm.git
>
> Otherwise yes, as much as reasonable we should avoid topic merges
> between the trees.
>
> However, I again see conflict risk coming this cycle ..
>
> >  And I don't think there will be a real conflict like this every
> > merge window, this should be the exception.  Worst case we have to
> > stage some work 1 release cycle apart, i.e.  merge mm stuff first,
> > then drm 3 months later.
>
> I really dislike this idea. Not being able to provide users for core
> APIs is a huge process/review problem. Worse it tends to create a
> 'ladder' where in-flight changes to drivers (to implement the new
> core) now block any changes to the core APIs on alternating cycles. So
> 'the big pitcture' starts to fall a part if we can't co-ordinate cross
> tree changes in some way.
>
> .. and honestly, splitting a review process across a 9 week gap is one
> of the best ways I've seen to get a poor quality review :(
>
> I'm pretty familiar with this problem, we had it in spades between RDMA
> and netdev for a long time, and it is finally fully resolved now
> through a careful use of topic branches and merges.
>
> For example, next week I'll queue CH's patches that shift the last
> batch of hmm 'conflict management' shims into nouveau, and tries to
> fix them:
>
>   https://patchwork.kernel.org/project/linux-mm/list/?series=141835
>
> This is something uncontroversial that really should go into the DRM
> world as a topic so it doesn't interfere with ongoing nouveau dev. But
> I want to keep the hmm.c/.h bits in the hmm.git to avoid conflicts.
>
> So, I'll put it on a topic and send you two a note next week to decide
> if you want to merge it or not. I'm really unclear how nouveau's and
> AMD's patchflow works..

DRM is 2-level for pretty much everything. First it lands in a driver
tree (or a collectiv of drivers, like in drm-misc). Then those send
pull requests to drm.git for integration. Busy trees do that every 1-2
weeks (e.g. amdgpu), slower trees once per merge window (e.g. nouveau)
for drm-next, similar for drm-fixes.
-Daniel




--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch