All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Kuehling <felix.kuehling@amd.com>
To: Daniel Vetter <daniel@ffwll.ch>, Thomas Zimmermann <tzimmermann@suse.de>
Cc: amd-gfx@lists.freedesktop.org, shashank.sharma@amd.com,
	airlied@linux.ie,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	sroland@vmware.com, nirmoy.das@amd.com,
	dri-devel@lists.freedesktop.org, ray.huang@amd.com,
	linux-graphics-maintainer@vmware.com, bskeggs@redhat.com,
	nouveau@lists.freedesktop.org, alexander.deucher@amd.com,
	sam@ravnborg.org, "Christian König" <christian.koenig@amd.com>,
	zackr@vmware.com, emil.velikov@collabora.com
Subject: Re: [Nouveau] [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
Date: Tue, 20 Apr 2021 16:22:58 -0400	[thread overview]
Message-ID: <a76b44d2-d894-ab4e-ef37-f0feb4326297@amd.com> (raw)
In-Reply-To: <YH6WJ0p2jGd3Q5Xw@phenom.ffwll.local>


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.

Regards,
  Felix


>
>
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

WARNING: multiple messages have this Message-ID (diff)
From: Felix Kuehling <felix.kuehling@amd.com>
To: Daniel Vetter <daniel@ffwll.ch>, Thomas Zimmermann <tzimmermann@suse.de>
Cc: amd-gfx@lists.freedesktop.org, shashank.sharma@amd.com,
	airlied@linux.ie,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	sroland@vmware.com, nirmoy.das@amd.com,
	dri-devel@lists.freedesktop.org, ray.huang@amd.com,
	linux-graphics-maintainer@vmware.com, bskeggs@redhat.com,
	nouveau@lists.freedesktop.org, alexander.deucher@amd.com,
	sam@ravnborg.org, "Christian König" <christian.koenig@amd.com>,
	emil.velikov@collabora.com
Subject: Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
Date: Tue, 20 Apr 2021 16:22:58 -0400	[thread overview]
Message-ID: <a76b44d2-d894-ab4e-ef37-f0feb4326297@amd.com> (raw)
In-Reply-To: <YH6WJ0p2jGd3Q5Xw@phenom.ffwll.local>


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.

Regards,
  Felix


>
>
_______________________________________________
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: Felix Kuehling <felix.kuehling@amd.com>
To: Daniel Vetter <daniel@ffwll.ch>, Thomas Zimmermann <tzimmermann@suse.de>
Cc: amd-gfx@lists.freedesktop.org, shashank.sharma@amd.com,
	airlied@linux.ie,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	sroland@vmware.com, nirmoy.das@amd.com,
	dri-devel@lists.freedesktop.org, ray.huang@amd.com,
	linux-graphics-maintainer@vmware.com, bskeggs@redhat.com,
	nouveau@lists.freedesktop.org, alexander.deucher@amd.com,
	sam@ravnborg.org, "Christian König" <christian.koenig@amd.com>,
	zackr@vmware.com, emil.velikov@collabora.com
Subject: Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
Date: Tue, 20 Apr 2021 16:22:58 -0400	[thread overview]
Message-ID: <a76b44d2-d894-ab4e-ef37-f0feb4326297@amd.com> (raw)
In-Reply-To: <YH6WJ0p2jGd3Q5Xw@phenom.ffwll.local>


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.

Regards,
  Felix


>
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2021-04-20 20:23 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           ` Felix Kuehling [this message]
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                 ` [Nouveau] " Daniel Vetter
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=a76b44d2-d894-ab4e-ef37-f0feb4326297@amd.com \
    --to=felix.kuehling@amd.com \
    --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=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.velikov@collabora.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=tzimmermann@suse.de \
    --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.