Re: [PATCH 1/1] drm/amdgpu: adopt to hmm_range_register API change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 3, 2019 at 5:03 PM Kuehling, Felix <Felix.Kuehling@xxxxxxx> wrote:
>
> On 2019-07-03 10:10 a.m., Jason Gunthorpe wrote:
> > On Wed, Jul 03, 2019 at 01:55:08AM +0000, Kuehling, Felix wrote:
> >> From: Philip Yang <Philip.Yang@xxxxxxx>
> >>
> >> In order to pass mirror instead of mm to hmm_range_register, we need
> >> pass bo instead of ttm to amdgpu_ttm_tt_get_user_pages because mirror
> >> is part of amdgpu_mn structure, which is accessible from bo.
> >>
> >> Signed-off-by: Philip Yang <Philip.Yang@xxxxxxx>
> >> Reviewed-by: Felix Kuehling <Felix.Kuehling@xxxxxxx>
> >> Signed-off-by: Felix Kuehling <Felix.Kuehling@xxxxxxx>
> >> CC: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
> >> CC: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
> >> CC: Dave Airlie <airlied@xxxxxxxx>
> >> CC: Alex Deucher <alexander.deucher@xxxxxxx>
> >> ---
> >>   drivers/gpu/drm/Kconfig                          |  1 -
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c |  5 ++---
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c           |  2 +-
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c          |  3 +--
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c           |  8 ++++++++
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h           |  5 +++++
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c          | 12 ++++++++++--
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h          |  5 +++--
> >>   8 files changed, 30 insertions(+), 11 deletions(-)
> > This is too big to use as a conflict resolution, what you could do is
> > apply the majority of the patch on top of your tree as-is (ie keep
> > using the old hmm_range_register), then the conflict resolution for
> > the updated AMD GPU tree can be a simple one line change:
> >
> >   -   hmm_range_register(range, mm, start,
> >   +   hmm_range_register(range, mirror, start,
> >                          start + ttm->num_pages * PAGE_SIZE, PAGE_SHIFT);
> >
> > Which is trivial for everone to deal with, and solves the problem.
>
> Good idea.
>
>
> >
> > This is probably a much better option than rebasing the AMD gpu tree.
>
> I think Alex is planning to merge hmm.git into an updated drm-next and
> then rebase amd-staging-drm-next on top of that. Rebasing our
> amd-staging-drm-next is something we do every month or two anyway.
>

Go ahead and respin your patch as per the suggestion above.  then I
can apply it I can either merge hmm into amd's drm-next or we can just
provide the conflict fix patch whichever is easier.  Which hmm branch
is for 5.3?
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/?h=hmm


>
> >
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> >> index 623f56a1485f..80e40898a507 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> >> @@ -398,6 +398,14 @@ struct amdgpu_mn *amdgpu_mn_get(struct amdgpu_device *adev,
> >>      return ERR_PTR(r);
> >>   }
> >>
> >> +struct hmm_mirror *amdgpu_mn_get_mirror(struct amdgpu_mn *amn)
> >> +{
> >> +    if (!amn)
> >> +            return NULL;
> >> +
> >> +    return &amn->mirror;
> >> +}
> > I think it is better make the struct amdgpu_mn public rather than add
> > this wrapper.
>
> Sure. I can do that. It won't make the patch smaller, though, if that
> was your intention.
>
> It looks like Stephen already applied my patch as a conflict resolution
> on linux-next, though. I see linux-next/master is getting updated
> non-fast-forward. So is the idea that its history will updated again
> with the final resolution on drm-next or drm-fixes?
>

linux-next can deal with rebases, etc.  If the contributing trees
rebase or change, linux-next will update.

Alex

> Regards,
>    Felix
>
> >
> > Jason
> >
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux