Nouveau - Apr 2021 - [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter:
>>> Whole series is Reviewed-by: Christian K?nig <christian.koenig
at 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

>
>

On Tue, Apr 20, 2021 at 10:23 PM Felix Kuehling <felix.kuehling at
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 at 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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch