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

[Zack Rusin]

> On Dec 3, 2020, at 10:12, Daniel Vetter <daniel at ffwll.ch> wrote:
> 
> 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.

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