> 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.

z
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to