[PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

[Daniel Vetter]

On Thu, Dec 03, 2020 at 03:06:20AM +0000, Zack Rusin wrote:
> 
> 
> > On Dec 2, 2020, at 11:03, Daniel Vetter <daniel at ffwll.ch> wrote:
> > 
> > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <zackr at vmware.com> wrote:
> >> 
> >> 
> >> 
> >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann at 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 <tzimmermann at 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 <tzimmermann at suse.de>
> >>>>>> Cc: Roland Scheidegger <sroland at 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 <zackr at 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