Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: "amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Sharma, Shashank" <shashank.sharma@amd.com>,
	"Dave Airlie" <airlied@linux.ie>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"Felix Kuehling" <felix.kuehling@amd.com>,
	"Roland Scheidegger" <sroland@vmware.com>,
	"Nirmoy Das" <nirmoy.das@amd.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Huang Rui" <ray.huang@amd.com>,
	"VMware Graphics" <linux-graphics-maintainer@vmware.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Nouveau Dev" <nouveau@lists.freedesktop.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Zack Rusin" <zackr@vmware.com>,
	"Emil Velikov" <emil.velikov@collabora.com>
Subject: Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
Date: Wed, 21 Apr 2021 11:12:22 +0200	[thread overview]
Message-ID: <YH/sdlVA5dG51LP0@phenom.ffwll.local> (raw)
In-Reply-To: <a60d976a-8b1e-b0bb-07ba-f5801242b86c@amd.com>

On Wed, Apr 21, 2021 at 09:01:00AM +0200, Christian König wrote:
> Am 20.04.21 um 22:53 schrieb Daniel Vetter:
> > On Tue, Apr 20, 2021 at 10:23 PM Felix Kuehling <felix.kuehling@amd.com> wrote:
> > > 
> > > Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter:
> > > > > > Whole series is Reviewed-by: Christian König <christian.koenig@amd.com>
> > > > > Thanks a lot. If I'm not mistaken, the patches at [1] need to go in first.
> > > > > So it could take a a bit until this lands.
> > > > > 
> > > > > Otherwise, this series could go through the same tree as [1] if nouveau and
> > > > > vmwgfx devs don't mind.
> > > > I would land it all through drm-misc-next. Maybe check with Alex on irc
> > > > for an ack for merging that way, but I don't think this will cause issues
> > > > against the amdgpu tree. Lots of ttm cleanup has landed this way already
> > > > past few months. Otherwise you could create a small topic branch with
> > > > these patches here and send that to Alex, and he can sort out the
> > > > interaction with Felix' series.
> > > > -Daniel
> > > My patch series involved some pretty far-reaching changes in KFD
> > > (renaming some variables in KFD and amdgpu, changing the KFD->amdgpu
> > > interface). We already submitted other patches on top of it that have
> > > dependencies on it. If we decide to deliver this through a different
> > > tree and remove it from amd-staging-drm-next, there will be conflicts to
> > > resolve when removing it from amd-staging-drm-next, and again the next
> > > time you merge with amd-staging-drm-next.
> > Ah then the usual way is for Alex to assemble a topic pull request
> > (stable, non-rebasing) with those select patches, which then gets
> > merged into drm-misc-next. Or we smash it all into amdgpu-next. Or we
> > just wait until -rc2 when drm-next is back open for business.
> 
> I need to double check, but if I'm not totally mistaken the changes in
> question should already be in drm-next.
> 
> But exactly that was the reason why I asked when the next backmerge from
> drm-next into drm-misc-next is planned :)

Best way to make that happen isn't to ask when it will happen, but tell
drm-misc maintainers to do it and why (ideally with references to the
commits you need). Also I tend to do those requests over irc.

Backmerges are generally on demand, not on schedule. Hence you need to
demand one :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx