Am 06.04.21 um 17:42 schrieb Felix Kuehling:
Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher:
Hi Dave, Daniel,
New stuff for 5.13. There are two small patches for ttm and scheduler
that were dependencies for amdgpu changes.
The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60eb
771763840
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
771763840
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
771763840
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Hey Christian, Denis, see bellow -
On 2021-04-06 6:34 a.m., Christian König wrote:
Hi Andrey,
well good question. My job is to watch over the implementation and
design and while I always help I can adjust anybodies schedule.
Is the patch to print a warning when the hardware is accessed witho
On Mon, Mar 22, 2021 at 6:34 AM Christian König
wrote:
>
> Hi Daniel,
>
> Am 22.03.21 um 10:38 schrieb Daniel Gomez:
> > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling wrote:
> >> This caused a regression in kfdtest in a large-buffer stress test after
> >> memory allocation for user pages fails:
>
On Fri, Apr 2, 2021 at 12:22 PM Christian König
wrote:
>
> Hey Alex,
>
> the TTM and scheduler changes should already be in the drm-misc-next
> branch (not 100% sure about the TTM patch, need to double check next week).
>
The TTM change is not in drm-misc yet.
> Could that cause problems when bo
[AMD Public Use]
Reviewed-by: Lijo Lazar
-Original Message-
From: Zhang, Hawking
Sent: Tuesday, April 6, 2021 9:35 PM
To: amd-gfx@lists.freedesktop.org; Lazar, Lijo ; Deucher,
Alexander ; Clements, John
Cc: Zhang, Hawking
Subject: [PATCH] drm/amdgpu: move mmhub ras_func init to ip s
mmhub ras is always owned by gpu driver. ras_funcs
initialization shall be done at ip level, instead of
putting it in common gmc interface file
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 19 ---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 19
Am 2021-04-06 um 7:13 a.m. schrieb Christian König:
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>> @@ -1042,13 +1042,15 @@ int
>>> amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, u32 pasid,
>>>
On Tue, Apr 6, 2021 at 11:42 AM Felix Kuehling wrote:
>
> Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher:
> > Hi Dave, Daniel,
> >
> > New stuff for 5.13. There are two small patches for ttm and scheduler
> > that were dependencies for amdgpu changes.
> >
> > The following changes since commit 2
Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher:
> Hi Dave, Daniel,
>
> New stuff for 5.13. There are two small patches for ttm and scheduler
> that were dependencies for amdgpu changes.
>
> The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7:
>
> Merge tag 'amd-drm-next-
Am 2021-04-01 um 2:22 p.m. schrieb Alex Deucher:
> On Thu, Apr 1, 2021 at 10:08 AM Smith John wrote:
>> Hi, when I killed an OpenCL host process, the kernels it launched were not
>> terminated, and still run.
>>
>> My OpenCL runtime is AMDGPU-PRO 20.20. OS Ubuntu 18.04.5 with Linux Kernel
>> 5.
Am 2021-04-06 um 6:38 a.m. schrieb Thomas Zimmermann:
> Hi
>
> Am 06.04.21 um 11:35 schrieb Christian König:
>> Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
>>> Moving the driver-specific mmap code into a GEM object function allows
>>> for using DRM helpers for various mmap callbacks.
>>>
>>> Th
Am 2021-04-06 um 9:04 a.m. schrieb Christian König:
> Am 06.04.21 um 14:52 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 06.04.21 um 14:42 schrieb Christian König:
>>> Hi Thomas,
>>>
>>> Am 06.04.21 um 13:55 schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 12:56 schrieb Christian König:
[AMD Official Use Only - Internal Distribution Only]
Hi Nicholas,
Let me summarize the suggestion. Please correct me if I misunderstood.
1. for dmub_aux_transfer_done, move it to amdgpu_display_manager in amdgpu_dm.h
instead of amdgpu.h
2. Remove DC_ENABLE_DMUB_AUX from amd_shared.h at current
From: Xuezhi Zhang
Fix the following coccicheck warning:
drivers/gpu/drm/amd/pm//amdgpu_pm.c:1940:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/amd/pm//amdgpu_pm.c:1978:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/amd/pm//amdgpu_pm.c:2022:8-16:
WARNING: use scnprintf or sp
On 2021-04-06 10:22 a.m., Shih, Jude wrote:
[AMD Official Use Only - Internal Distribution Only]
Hi Nicholas,
Does this completion need to be on the amdgpu device itself?
I would prefer if we keep this as needed within DM itself if possible.
=> do you mean move it to amdgpu_display_manager in
[AMD Official Use Only - Internal Distribution Only]
Hi Nicholas,
Does this completion need to be on the amdgpu device itself?
I would prefer if we keep this as needed within DM itself if possible.
=> do you mean move it to amdgpu_display_manager in amdgpu_dm.h as global
variable?
My problem
On Tue, Apr 6, 2021 at 5:09 AM Thomas Zimmermann wrote:
>
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
>
> This change also allows to support prime-based mmap via DRM's helper
> drm_gem_prime_mmap().
>
> Permission che
On 2021-04-06 9:40 a.m., Jude Shih wrote:
[Why & How]
We use outbox interrupt that allows us to do the AUX via DMUB
Therefore, we need to add some irq source related definition
in the header files;
Also, I added debug flag that allows us to turn it on/off
for testing purpose.
Signed-off-by: Jude
Hi Qu,
Am 06.04.21 um 08:04 schrieb Qu Huang:
Hi Christian,
On 2021/4/3 16:49, Christian König wrote:
Hi Qu,
Am 03.04.21 um 07:08 schrieb Qu Huang:
Hi Christian,
On 2021/4/3 0:25, Christian König wrote:
Hi Qu,
Am 02.04.21 um 05:18 schrieb Qu Huang:
Before dma_resv_lock(bo->base.resv, NUL
[Why & How]
We use outbox interrupt that allows us to do the AUX via DMUB
Therefore, we need to add some irq source related definition
in the header files;
Also, I added debug flag that allows us to turn it on/off
for testing purpose.
Signed-off-by: Jude Shih
---
drivers/gpu/drm/amd/amdgpu/amdgp
Hi Christian,
On 2021/4/3 16:49, Christian König wrote:
Hi Qu,
Am 03.04.21 um 07:08 schrieb Qu Huang:
Hi Christian,
On 2021/4/3 0:25, Christian König wrote:
Hi Qu,
Am 02.04.21 um 05:18 schrieb Qu Huang:
Before dma_resv_lock(bo->base.resv, NULL) in
amdgpu_bo_release_notify(),
the bo->base.r
On 2021-03-31 11:21 p.m., Jude Shih wrote:
[Why & How]
We use outbox interrupt that allows us to do the AUX via DMUB
Therefore, we need to add some irq source related definition
in the header files;
Also, I added debug flag that allows us to turn it on/off
for testing purpose.
Missing your sign
Am 06.04.21 um 14:52 schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 14:42 schrieb Christian König:
Hi Thomas,
Am 06.04.21 um 13:55 schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 12:56 schrieb Christian König:
In the end I went with the semantics I found in amdgpu_mmap() and
handled KFD specia
Hi
Am 06.04.21 um 14:42 schrieb Christian König:
Hi Thomas,
Am 06.04.21 um 13:55 schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 12:56 schrieb Christian König:
In the end I went with the semantics I found in amdgpu_mmap() and
handled KFD specially. Let me know if this requires to be changed.
Am 06.04.21 um 14:21 schrieb Roy Sun:
Move the process of cancelling hrtimer to sw_fini
They why you want to do this is missing here.
Apart from that looks a bit odd to cancel the timer this late.
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 12 +---
1 f
Hi Thomas,
Am 06.04.21 um 13:55 schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 12:56 schrieb Christian König:
In the end I went with the semantics I found in amdgpu_mmap() and
handled KFD specially. Let me know if this requires to be changed.
Well the question is where is the call to
drm_vm
Move the process of cancelling hrtimer to sw_fini
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
index 5c1114
Hi
Am 06.04.21 um 12:56 schrieb Christian König:
In the end I went with the semantics I found in amdgpu_mmap() and
handled KFD specially. Let me know if this requires to be changed.
Well the question is where is the call to drm_vma_node_verify_access()
now? Cause that needs to be skipped fo
Am 06.04.21 um 12:34 schrieb Christian König:
Hi Andrey,
well good question. My job is to watch over the implementation and
design and while I always help I can adjust anybodies schedule.
That should read "I can't adjust anybodies schedule".
Christian.
Is the patch to print a warning wh
Am 06.04.21 um 12:54 schrieb Nirmoy:
On 4/6/21 11:49 AM, Roy Sun wrote:
Tracking devices, process info and fence info using
/proc/pid/fdinfo
First of all please separate the patch into the handling for the DRM
file descriptors and KFD file descriptors.
Signed-off-by: David M Nieto
Sig
Hi Thomas,
Am 06.04.21 um 12:38 schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 11:35 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change res
On 4/6/21 11:49 AM, Roy Sun wrote:
Tracking devices, process info and fence info using
/proc/pid/fdinfo
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +
.../gpu/drm/amd/a
Hi
Am 06.04.21 um 11:35 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-
Hi Andrey,
well good question. My job is to watch over the implementation and
design and while I always help I can adjust anybodies schedule.
Is the patch to print a warning when the hardware is accessed without
holding the locks merged yet? If not then that would probably be a good
starting
Hi
Am 06.04.21 um 11:43 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Remove an unused function. Mapping the fbdev framebuffer is apparently
not supported.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Should I just upstream this through our inte
Tracking devices, process info and fence info using
/proc/pid/fdinfo
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 15 +-
dri
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Remove an unused function. Mapping the fbdev framebuffer is apparently
not supported.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Should I just upstream this through our internal branches?
Thanks,
Christian.
---
drivers/
Am 06.04.21 um 11:09 schrieb Thomas Zimmermann:
The function ttm_bo_mmap is unused. Remove it and it's helpers; including
the verify_access callback in struct ttm_device_funcs.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 53
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change also allows to support prime-based mmap via DRM's helper
drm_gem_prime_mmap().
Permission checks are implemented b
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for
On Tue, Apr 06, 2021 at 03:29:48PM +0800, Zhu, Changfeng wrote:
> From: changzhu
>
> From: Changfeng
>
> It needs to add amdgpu_sriov_fullaccess judgement as gfx_v10_rlcg_wreg
> when doing gfx_v9_0_rlcg_wreg.
> Or it will cause modprobe issue as below:
> kernel: [ 59.992843] amdgpu: timeout:
The function ttm_bo_mmap is unused. Remove it and it's helpers; including
the verify_access callback in struct ttm_device_funcs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 53 -
include/drm/ttm/ttm_bo_api.h| 13
include/drm
Vmwgfx is the only user of the TTM's verify_access callback. Inline
the call and avoid the indirection through the function pointer.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 7 ++-
2 files chan
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 54 ++--
1 file changed, 51
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change also allows to support prime-based mmap via DRM's helper
drm_gem_prime_mmap().
Permission checks are implemented by drm_gem_mmap(), with an additional
check for rad
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The GEM object function is provided by GEM TTM helpers. Nouveau's
implementation of verify_access is unused and has been removed. Access
permissions are validated by the DRM hel
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for
Drivers may want to set their own callbacks for a VM area. Only set
TTM's callbacks if the vm_ops field is clear.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drive
Remove an unused function. Mapping the fbdev framebuffer is apparently
not supported.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 --
2 files changed, 21 deletions(-)
diff --git a/drive
Implement mmap via struct drm_gem_object_functions.mmap for amdgpu,
radeon and nouveau. This allows for using common DRM helpers for
the mmap-related callbacks in struct file_operations and struct
drm_driver. The drivers have their own vm_ops, which are now set
automatically by the DRM core functio
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Emily Deng
>-Original Message-
>From: Zhu, Changfeng
>Sent: Tuesday, April 6, 2021 3:30 PM
>To: amd-gfx@lists.freedesktop.org; Huang, Ray ;
>Zhou, Peng Ju ; Deng, Emily
>Cc: Zhu, Changfeng
>Subject: [PATCH] drm/amdgpu:
From: changzhu
From: Changfeng
It needs to add amdgpu_sriov_fullaccess judgement as gfx_v10_rlcg_wreg
when doing gfx_v9_0_rlcg_wreg.
Or it will cause modprobe issue as below:
kernel: [ 59.992843] amdgpu: timeout: rlcg program reg:0x02984 failed!
Fix for patch:
drm/amdgpu: indirect register a
Yes, Andrey is right.
A top level explanation is that we don't prevent moving the buffer but
rather we prevent user space from accessing it.
Regards,
Christian.
Am 05.04.21 um 18:34 schrieb Andrey Grodzovsky:
From my understanding and looking at the code I think we don't prevent
but rather
56 matches
Mail list logo
