> On Dec 3, 2020, at 10:12, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Thu, Dec 03, 2020 at 03:06:20AM +0000, Zack Rusin wrote: >> >> >>> On Dec 2, 2020, at 11:03, Daniel Vetter <daniel@xxxxxxxx> wrote: >>> >>> On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <zackr@xxxxxxxxxx> wrote: >>>> >>>> >>>> >>>>> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann@xxxxxxx> 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 <tzimmermann@xxxxxxx> wrote: >>>>>>>> >>>>>>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct >>>>>>>> drm_device.dev. No functional changes. >>>>>>>> >>>>>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx> >>>>>>>> Cc: Roland Scheidegger <sroland@xxxxxxxxxx> >>>>>>>> --- >>>>>>>> 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 <zackr@xxxxxxxxxx> >>>>>> 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. Perfect, thanks a lot! This has been something I wanted our driver to do for a while, I’ll go ahead and switch our internal dev to drm-misc. z _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
