On Thu, Dec 03, 2020 at 03:06:20AM +0000, Zack Rusin wrote: > > > > On Dec 2, 2020, at 11:03, Daniel Vetter <dan...@ffwll.ch> wrote: > > > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <za...@vmware.com> wrote: > >> > >> > >> > >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmerm...@suse.de> wrote: > >>> > >>> Hi > >>> > >>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > >>>> Hi > >>>> Am 30.11.20 um 21:59 schrieb Zack Rusin: > >>>>> > >>>>> > >>>>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmerm...@suse.de> > >>>>>> wrote: > >>>>>> > >>>>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > >>>>>> drm_device.dev. No functional changes. > >>>>>> > >>>>>> Signed-off-by: Thomas Zimmermann <tzimmerm...@suse.de> > >>>>>> Cc: Roland Scheidegger <srol...@vmware.com> > >>>>>> --- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > >>>>> > >>>>> Reviewed-by: Zack Rusin <za...@vmware.com> > >>>> Could you add this patch to the vmwgfx tree? > >>> > >>> AMD devs indicated that they'd prefer to merge the patchset trough > >>> drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through > >>> drm-misc-next as well. > >> > >> Sounds good. I’ll make sure to rebase our latest patch set on top of it > >> when it’s in. Thanks! > > > > btw if you want to avoid multi-tree coordination headaches, we can > > also manage vmwgfx in drm-misc and give you & Roland commit rights > > there. Up to you. There is some scripting involved for now (but I hope > > whenever we move to gitlab we could do the checks server-side): > > I’d be happy to take you up on that. I would like to move a lot more of > our development into public repos and reducing the burden of maintaining > multiple trees would help. Is there a lot of changes to drm core that > doesn’t go through drm-misc? Or alternatively is drm-misc often pulling > from Linus’ master? I’m trying to figure out how much would our need to > rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes > because that would also allow me to point some internal testing > infrastructure at it as well.
I think nowadays pretty much all the cross-driver work lands through drm-misc. Exception is just new stuff that's only used by a single driver. For testing there's also drm-tip, which tries to pull it all together (but you might still want to point your CI at branches). Also note that drm-misc-next doesn't have a merge window freeze period (with have the drm-misc-next-fixes branch during that time for merge window fixes), so you can treat it like a main development branch like e.g. in mesa, with the -fixes branches as the release branches. Only difference is that we don't cherry pick patches from the main branch to the release branches (at least not as the normal flow). If you do need a backmerge for patches from Linus to drm-misc-next because of some feature work (or conflicts with other stuff in general) drm-misc maintainers do that. Usually happens every few weeks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
