On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel <pmenzel@xxxxxxxxxxxxx> wrote: > > Dear Christian, > > > Am 05.04.22 um 08:54 schrieb Christian König: > > Am 05.04.22 um 08:45 schrieb Paul Menzel: > > >> Am 04.04.22 um 23:42 schrieb Philip Yang: > >>> bo_adev is NULL for system memory mapping to GPU. > >>> > >>> Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction) > >> > >> Sorry, where can I find that commit? > > > > Well that's expected, the development branch is not public. > > Well obviously, it was unexpected for me. How should I have known? Where > is that documented? If the patches are publicly posted to the mailing > list, why is that development branch not public? > > The current situation is really frustrating for non-AMD employees. How > can the current situation be improved? Our development branch (https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next) is available publicly. There can be a day or so of lag depending on when it gets mirrored (e.g., over the weekend). Alex > > > Kind regards, > > Paul > > > >> I do not see it in drm-next from agd5f git archive > >> git@xxxxxxxxxxxxxxxxxxxxxx:agd5f/linux.git. > >> > >> $ git log --oneline -1 > >> e45422695c19 (HEAD, agd5f/drm-next) drm/amdkfd: Create file > >> descriptor after client is added to smi_clients list > >> > >> > >> Kind regards, > >> > >> Paul > >> > >> > >>> Signed-off-by: Philip Yang <Philip.Yang@xxxxxxx> > >>> --- > >>> drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c > >>> b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c > >>> index 907b02045824..d3fb2d0b5a25 100644 > >>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c > >>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c > >>> @@ -1281,7 +1281,7 @@ svm_range_map_to_gpu(struct kfd_process_device > >>> *pdd, struct svm_range *prange, > >>> last_start, prange->start + i, > >>> pte_flags, > >>> last_start - prange->start, > >>> - bo_adev->vm_manager.vram_base_offset, > >>> + bo_adev ? > >>> bo_adev->vm_manager.vram_base_offset : 0, > >>> NULL, dma_addr, &vm->last_update); > >>> for (j = last_start - prange->start; j <= i; j++)