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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
