All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	"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: [Nouveau] [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
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: "amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	"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>,
	"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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2021-04-21  9:12 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 13:31 [Nouveau] [PATCH v3 0/7] drm: Clean up mmap for TTM-based GEM drivers Thomas Zimmermann
2021-04-16 13:31 ` Thomas Zimmermann
2021-04-16 13:31 ` Thomas Zimmermann
2021-04-16 13:31 ` [Nouveau] [PATCH v3 1/7] drm/ttm: Don't override vm_ops callbacks, if set Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31 ` [Nouveau] [PATCH v3 2/7] drm/amdgpu: Implement mmap as GEM object function Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31 ` [Nouveau] [PATCH v3 3/7] drm/radeon: " Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31 ` [Nouveau] [PATCH v3 4/7] drm/nouveau: " Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31 ` [Nouveau] [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:46   ` [Nouveau] " Christian König
2021-04-16 13:46     ` Christian König
2021-04-16 13:46     ` Christian König
2021-04-16 13:51     ` [Nouveau] " Christian König
2021-04-16 13:51       ` Christian König
2021-04-16 13:51       ` Christian König
2021-04-20  7:51       ` [Nouveau] " Thomas Zimmermann
2021-04-20  7:51         ` Thomas Zimmermann
2021-04-20  7:51         ` Thomas Zimmermann
2021-04-20  8:51         ` [Nouveau] " Daniel Vetter
2021-04-20  8:51           ` Daniel Vetter
2021-04-20  8:51           ` Daniel Vetter
2021-04-20 20:22           ` [Nouveau] " Felix Kuehling
2021-04-20 20:22             ` Felix Kuehling
2021-04-20 20:22             ` Felix Kuehling
2021-04-20 20:53             ` [Nouveau] " Daniel Vetter
2021-04-20 20:53               ` Daniel Vetter
2021-04-20 20:53               ` Daniel Vetter
2021-04-21  7:01               ` [Nouveau] " Christian König
2021-04-21  7:01                 ` Christian König
2021-04-21  7:01                 ` Christian König
2021-04-21  9:12                 ` Daniel Vetter [this message]
2021-04-21  9:12                   ` Daniel Vetter
2021-04-21  9:12                   ` Daniel Vetter
2021-04-16 14:00     ` [Nouveau] " Thomas Zimmermann
2021-04-16 14:00       ` Thomas Zimmermann
2021-04-16 14:00       ` Thomas Zimmermann
2021-04-16 13:31 ` [Nouveau] [PATCH v3 6/7] drm/vmwgfx: Inline vmw_verify_access() Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31 ` [Nouveau] [PATCH v3 7/7] drm/ttm: Remove ttm_bo_mmap() and friends Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:31   ` Thomas Zimmermann
2021-04-16 13:44 ` [Nouveau] [PATCH v3 0/7] drm: Clean up mmap for TTM-based GEM drivers Christian König
2021-04-16 13:44   ` Christian König
2021-04-16 13:44   ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YH/sdlVA5dG51LP0@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bskeggs@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.velikov@collabora.com \
    --cc=felix.kuehling@amd.com \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=nirmoy.das@amd.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ray.huang@amd.com \
    --cc=sam@ravnborg.org \
    --cc=shashank.sharma@amd.com \
    --cc=sroland@vmware.com \
    --cc=zackr@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.