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
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
[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
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
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
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
>>
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.
>>>
>>>
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
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
[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
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:
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,
[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
---
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
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
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
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.
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
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
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
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
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
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
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 +
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
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
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
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 +-
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.
---
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
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
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
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,
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
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
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
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
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
[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
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
[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.
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h
55 matches
Mail list logo
