Re: [PATCH v4] drm/gem: Make the GEM LRU lock part of drm_device

[Simona Vetter <simona.vetter@ffwll.ch>]

On Tue, May 19, 2026 at 01:51:53PM +0200, Boris Brezillon wrote:
> On Tue, 19 May 2026 12:37:16 +0100
> Mark Brown <broonie@kernel.org> wrote:
> 
> > On Mon, May 18, 2026 at 04:52:25PM +0200, Boris Brezillon wrote:
> > > +Mark for the silent conflict resolution needed to reconcile
> > > drm-misc-fixes and drm-next/drm-misc-next.  
> > 
> > This doesn't appear to be a drm-misc thing, I was seeing issues on the
> > DRM tree.  The patch does seem to ahve resolved things though.  Please
> > consider topic branches!
> 
> I'm just following the dim guide for resolution of conflicts between
> drm trees[1], so that's probably something to discuss with the
> DRM/DRM-misc maintainers. As for the suggestion to use topic branches,
> I've never heard of it being used for -fixes vs -next conflict
> resolution, every time I've gone through this process it was for
> xxx-next vs yyy-next conflict (xxx and yyy being different subsystem
> trees).
> 
> Maxime, Thomas, Maarteen, Sima and/or Dave, any suggestion/opinion?

Yeah, in general we do substantially fewer topic branches than other
subsystems. That's fallout from the committer model, which just want a
branch to push their patches and be done with it all - they're not full
maintainers, we don't magically have more of those. And sometimes that
results in more of a mess than necessary.

We try to keep the mess in check by doing backmerges as needed, ideally
before applying a patch. It's not super well documented since when/how to
backmerge is part of the section for maintainers:

https://drm.pages.freedesktop.org/maintainer-tools/maintainer/maintainer-drm-misc.html

The assumption is that committers will ask maintainers for help if they're
trying to push a patch that results in tons of conflicts when applying
(since development should happen on top of linux-next or drm-tip). Could
probably improve that a bit. But also, often it's only clear after
applying that a fixup is needed, and then it's pushed already. And with
committers there's no undoing pushed patches. So it's just part of the
deal with having lots of committers imo that history is a bit more a mess
at times.

Cheers, Sima

> [1]https://drm.pages.freedesktop.org/maintainer-tools/committer/conflict-resolution.html

-- 
Simona Vetter
Software Engineer
http://blog.ffwll.ch