* [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu
@ 2022-04-04 21:42 Philip Yang
2022-04-04 23:47 ` Felix Kuehling
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Philip Yang @ 2022-04-04 21:42 UTC (permalink / raw)
To: amd-gfx; +Cc: Philip Yang, christian.koenig
bo_adev is NULL for system memory mapping to GPU.
Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
---
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++)
--
2.35.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu
2022-04-04 21:42 [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu Philip Yang
@ 2022-04-04 23:47 ` Felix Kuehling
2022-04-05 6:01 ` Christian König
2022-04-05 6:45 ` Paul Menzel
2 siblings, 0 replies; 11+ messages in thread
From: Felix Kuehling @ 2022-04-04 23:47 UTC (permalink / raw)
To: Philip Yang, amd-gfx; +Cc: christian.koenig
Am 2022-04-04 um 17:42 schrieb Philip Yang:
> bo_adev is NULL for system memory mapping to GPU.
>
> Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)
> Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
> ---
> 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++)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu
2022-04-04 21:42 [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu Philip Yang
2022-04-04 23:47 ` Felix Kuehling
@ 2022-04-05 6:01 ` Christian König
2022-04-05 6:45 ` Paul Menzel
2 siblings, 0 replies; 11+ messages in thread
From: Christian König @ 2022-04-05 6:01 UTC (permalink / raw)
To: Philip Yang, amd-gfx; +Cc: christian.koenig
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)
> Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
> ---
> 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++)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu
2022-04-04 21:42 [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu Philip Yang
2022-04-04 23:47 ` Felix Kuehling
2022-04-05 6:01 ` Christian König
@ 2022-04-05 6:45 ` Paul Menzel
2022-04-05 6:54 ` Christian König
2 siblings, 1 reply; 11+ messages in thread
From: Paul Menzel @ 2022-04-05 6:45 UTC (permalink / raw)
To: Philip Yang; +Cc: christian.koenig, amd-gfx
Dear Philip,
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? I do not see it in drm-next from
agd5f git archive git@gitlab.freedesktop.org: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@amd.com>
> ---
> 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++)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu
2022-04-05 6:45 ` Paul Menzel
@ 2022-04-05 6:54 ` Christian König
2022-04-05 7:01 ` Paul Menzel
0 siblings, 1 reply; 11+ messages in thread
From: Christian König @ 2022-04-05 6:54 UTC (permalink / raw)
To: Paul Menzel, Philip Yang; +Cc: amd-gfx
Am 05.04.22 um 08:45 schrieb Paul Menzel:
> Dear Philip,
>
>
> 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.
Regards,
Christian.
> I do not see it in drm-next from agd5f git archive
> git@gitlab.freedesktop.org: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@amd.com>
>> ---
>> 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++)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Public patches but non-public development branch (Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu)
2022-04-05 6:54 ` Christian König
@ 2022-04-05 7:01 ` Paul Menzel
0 siblings, 0 replies; 11+ messages in thread
From: Paul Menzel @ 2022-04-05 7:01 UTC (permalink / raw)
To: Christian König; +Cc: Philip Yang, dri-devel, amd-gfx
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?
Kind regards,
Paul
>> I do not see it in drm-next from agd5f git archive
>> git@gitlab.freedesktop.org: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@amd.com>
>>> ---
>>> 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++)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Public patches but non-public development branch (Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu)
@ 2022-04-05 7:01 ` Paul Menzel
0 siblings, 0 replies; 11+ messages in thread
From: Paul Menzel @ 2022-04-05 7:01 UTC (permalink / raw)
To: Christian König; +Cc: Daniel Vetter, Philip Yang, dri-devel, amd-gfx
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?
Kind regards,
Paul
>> I do not see it in drm-next from agd5f git archive
>> git@gitlab.freedesktop.org: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@amd.com>
>>> ---
>>> 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++)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Public patches but non-public development branch (Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu)
2022-04-05 7:01 ` Paul Menzel
(?)
@ 2022-04-05 13:14 ` Alex Deucher
2022-04-05 14:03 ` Public patches but non-public development branch Paul Menzel
-1 siblings, 1 reply; 11+ messages in thread
From: Alex Deucher @ 2022-04-05 13:14 UTC (permalink / raw)
To: Paul Menzel
Cc: Philip Yang, amd-gfx list, Christian König,
Maling list - DRI developers
On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel <pmenzel@molgen.mpg.de> 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@gitlab.freedesktop.org: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@amd.com>
> >>> ---
> >>> 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++)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Public patches but non-public development branch
2022-04-05 13:14 ` Alex Deucher
@ 2022-04-05 14:03 ` Paul Menzel
2022-04-05 14:13 ` Alex Deucher
0 siblings, 1 reply; 11+ messages in thread
From: Paul Menzel @ 2022-04-05 14:03 UTC (permalink / raw)
To: Alex Deucher; +Cc: Philip Yang, dri-devel, Christian König, amd-gfx
Dear Alex,
Am 05.04.22 um 15:14 schrieb Alex Deucher:
> On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel wrote:
>> 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).
Thank you for the clarification. As can be seen at hand, it still causes
confusion though.
commit 05fe8eeca927e29b81f3f2a799e9b9b88b0989a9
Author: Christian König <christian.koenig@amd.com>
AuthorDate: Wed Mar 30 10:53:15 2022 +0200
Commit: Christian König <christian.koenig@amd.com>
CommitDate: Fri Apr 1 11:05:51 2022 +0200
Today is Tuesday, so it wasn’t mirrored yesterday, on Monday.
To avoid this friction in the future, is there an automated way to
mirror the branches? git hooks should allow that to be done on every
push for example.
Kind regards,
Paul
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Public patches but non-public development branch
2022-04-05 14:03 ` Public patches but non-public development branch Paul Menzel
@ 2022-04-05 14:13 ` Alex Deucher
2022-04-05 14:16 ` Paul Menzel
0 siblings, 1 reply; 11+ messages in thread
From: Alex Deucher @ 2022-04-05 14:13 UTC (permalink / raw)
To: Paul Menzel
Cc: Philip Yang, Maling list - DRI developers, Christian König,
amd-gfx list
On Tue, Apr 5, 2022 at 10:03 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>
> Dear Alex,
>
>
> Am 05.04.22 um 15:14 schrieb Alex Deucher:
> > On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel wrote:
>
> >> 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).
>
> Thank you for the clarification. As can be seen at hand, it still causes
> confusion though.
>
> commit 05fe8eeca927e29b81f3f2a799e9b9b88b0989a9
> Author: Christian König <christian.koenig@amd.com>
> AuthorDate: Wed Mar 30 10:53:15 2022 +0200
> Commit: Christian König <christian.koenig@amd.com>
> CommitDate: Fri Apr 1 11:05:51 2022 +0200
>
> Today is Tuesday, so it wasn’t mirrored yesterday, on Monday.
>
> To avoid this friction in the future, is there an automated way to
> mirror the branches? git hooks should allow that to be done on every
> push for example.
It's a bit more complicated than that since we have various CI systems
and IT security policies involved, but we can look into it.
Alex
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Public patches but non-public development branch
2022-04-05 14:13 ` Alex Deucher
@ 2022-04-05 14:16 ` Paul Menzel
0 siblings, 0 replies; 11+ messages in thread
From: Paul Menzel @ 2022-04-05 14:16 UTC (permalink / raw)
To: Alex Deucher; +Cc: Philip Yang, amd-gfx, Christian König, dri-devel
Dear Alex,
Am 05.04.22 um 16:13 schrieb Alex Deucher:
> On Tue, Apr 5, 2022 at 10:03 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>> Am 05.04.22 um 15:14 schrieb Alex Deucher:
>>> On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel wrote:
>>
>>>> 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).
>>
>> Thank you for the clarification. As can be seen at hand, it still causes
>> confusion though.
>>
>> commit 05fe8eeca927e29b81f3f2a799e9b9b88b0989a9
>> Author: Christian König <christian.koenig@amd.com>
>> AuthorDate: Wed Mar 30 10:53:15 2022 +0200
>> Commit: Christian König <christian.koenig@amd.com>
>> CommitDate: Fri Apr 1 11:05:51 2022 +0200
>>
>> Today is Tuesday, so it wasn’t mirrored yesterday, on Monday.
>>
>> To avoid this friction in the future, is there an automated way to
>> mirror the branches? git hooks should allow that to be done on every
>> push for example.
>
> It's a bit more complicated than that since we have various CI systems
> and IT security policies involved, but we can look into it.
That’d be awesome. Thank you!
Kind regards,
Paul
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-04-05 14:16 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-04 21:42 [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu Philip Yang
2022-04-04 23:47 ` Felix Kuehling
2022-04-05 6:01 ` Christian König
2022-04-05 6:45 ` Paul Menzel
2022-04-05 6:54 ` Christian König
2022-04-05 7:01 ` Public patches but non-public development branch (Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu) Paul Menzel
2022-04-05 7:01 ` Paul Menzel
2022-04-05 13:14 ` Alex Deucher
2022-04-05 14:03 ` Public patches but non-public development branch Paul Menzel
2022-04-05 14:13 ` Alex Deucher
2022-04-05 14:16 ` Paul Menzel
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.