Fix coding style errors reported by checkpatch, specifically:
ERROR: space prohibited before that ',' (ctx:WxV)
+module_param_named(job_hang_limit, amdgpu_job_hang_limit, int ,0444);
^
ERROR: space required after that ',' (ctx:WxV)
Hi!
On 2023-04-04 04:50, Christian König wrote:
> Adding a bunch of people who have been involved in this before.
>
> Am 03.04.23 um 22:15 schrieb Joshua Ashton:
>> On 4/3/23 20:54, Christian König wrote:
>>> Am 03.04.23 um 21:40 schrieb Joshua Ashton:
[SNIP]
Anyway, please let me know
Update the invalid PTE flag setting to ensure, in addition
to transitioning the retry fault to a no-retry fault, it
also causes the wavefront to enter the trap handler. With the
current setting, it only transitions to a no-retry fault.
Signed-off-by: Mukul Joshi
---
On 2023-04-04 12:36, Shashank Sharma wrote:
>
> On 04/04/2023 18:30, Luben Tuikov wrote:
>> On 2023-03-29 12:04, Shashank Sharma wrote:
>>> From: Shashank Sharma
>>>
>>> This patch adds new functions to map/unmap a usermode queue into
>>> the FW, using the MES ring. As soon as this mapping is
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 6a53bda3aaf3de5edeea27d0b1d8781d067640b6 Add linux-next specific
files for 20230404
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202303082135.njdx1bij-...@intel.com
https
[+Christian]
OK, this comes from the ttm_bo_wait_ctx call in this section of
amdgpu_bo_move:
if ((old_mem->mem_type == TTM_PL_TT ||
old_mem->mem_type == AMDGPU_PL_PREEMPT) &&
new_mem->mem_type == TTM_PL_SYSTEM) {
r = ttm_bo_wait_ctx(bo, ctx);
On 04/04/2023 18:24, Luben Tuikov wrote:
On 2023-03-29 12:04, Shashank Sharma wrote:
From: Shashank Sharma
The FW expects us to allocate atleast one page as context space to
process gang, process, shadow, GDS and FW related work. This patch
creates a joint object for the same, and
On 04/04/2023 18:30, Luben Tuikov wrote:
On 2023-03-29 12:04, Shashank Sharma wrote:
From: Shashank Sharma
This patch adds new functions to map/unmap a usermode queue into
the FW, using the MES ring. As soon as this mapping is done, the
queue would be considered ready to accept the
On 2023-03-29 12:04, Shashank Sharma wrote:
> From: Shashank Sharma
>
> This patch adds new functions to map/unmap a usermode queue into
> the FW, using the MES ring. As soon as this mapping is done, the
> queue would be considered ready to accept the workload.
>
> V1: Addressed review
[Public]
> -Original Message-
> From: Sider, Graham
> Sent: Tuesday, April 4, 2023 12:00 PM
> To: Russell, Kent ; Somasekharan, Sreekant
> ; amd-gfx@lists.freedesktop.org
> Cc: Somasekharan, Sreekant
> Subject: RE: [PATCH] drm/amdkfd: On GFX11 check PCIe atomics support and set
>
On 2023-03-29 12:04, Shashank Sharma wrote:
> From: Shashank Sharma
>
> The FW expects us to allocate atleast one page as context space to
> process gang, process, shadow, GDS and FW related work. This patch
> creates a joint object for the same, and calculates GPU space offsets
> for each of
On 2023-03-29 12:04, Shashank Sharma wrote:
> From: Shashank Sharma
>
> A Memory queue descriptor (MQD) of a userqueue defines it in the harware's
> context. As MQD format can vary between different graphics IPs, we need gfx
> GEN specific handlers to create MQDs.
>
> This patch:
> - Introduces
On 2023-03-29 11:47, Shashank Sharma wrote:
> From: Shashank Sharma
>
> Rename doorbell.num_doorbells to doorbell.num_kernel_doorbells to
> make it more readable.
>
> Cc: Alex Deucher
> Cc: Christian Koenig
> Signed-off-by: Shashank Sharma
> ---
Is there any reason you break up the Cc list
[AMD Official Use Only - General]
Ping :)
Best,
Graham
> -Original Message-
> From: Kuehling, Felix
> Sent: Monday, March 20, 2023 12:16 PM
> To: Sider, Graham ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/amdgpu: add print for iommu translation mode
>
> On
On 2023-03-29 12:04, Shashank Sharma wrote:
> From: Shashank Sharma
>
> This patch adds skeleton code for amdgpu usermode queue. It contains:
> - A new files with init functions of usermode queues.
> - A queue context manager in driver private data.
>
> V1: Worked on design review comments from
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of
> Russell, Kent
> Sent: Tuesday, April 4, 2023 9:43 AM
> To: Somasekharan, Sreekant ; amd-
> g...@lists.freedesktop.org
> Cc: Somasekharan, Sreekant
> Subject: RE: [PATCH] drm/amdkfd: On GFX11 check PCIe atomics support and
>
[AMD Official Use Only - General]
> -Original Message-
> From: Kuehling, Felix
> Sent: Tuesday, April 4, 2023 9:59 PM
> To: Xiao, Shane ; amd-gfx@lists.freedesktop.org;
> Koenig, Christian
> Cc: Liu, Aaron ; Guo, Shikai
> Subject: Re: [PATCH 3/3] drm/amdgpu: DROP redundant
>
[AMD Official Use Only - General]
> -Original Message-
> From: Kuehling, Felix
> Sent: Tuesday, April 4, 2023 9:52 PM
> To: Xiao, Shane ; amd-gfx@lists.freedesktop.org;
> Koenig, Christian
> Cc: Liu, Aaron ; Guo, Shikai
> Subject: Re: [PATCH 2/3] amd/amdgpu: Inherit coherence flags
[AMD Official Use Only - General]
> -Original Message-
> From: Kuehling, Felix
> Sent: Tuesday, April 4, 2023 9:45 PM
> To: Christian König ; Xiao, Shane
> ; Koenig, Christian ;
> amd-gfx@lists.freedesktop.org; Yang, Philip
> Cc: Liu, Aaron ; Guo, Shikai
> Subject: Re: [PATCH 1/3]
Here is the backtrace from Jira:
Thu Nov 10 13:10:23 2022] Scheduling eviction of pid 97784 in 0 jiffies
[Thu Nov 10 13:10:23 2022] WARNING: CPU: 173 PID: 97784 at
/var/lib/dkms/amdgpu/5.16.9.22.20-1438746~20.04/build/amd/amdgpu/../amdkfd/kfd_device.c:878
If we keep the BO in the GTT domain, it means it will not be updated if
we validate it again later in kfd_mem_dmamap_dmabuf. This means we'll
use stale DMA addresses when we update the page tables after evictions.
I think we'll need to find a different way to avoid triggering the
eviction
Am 2023-04-04 um 05:56 schrieb Shane Xiao:
For DMA-MAP userptr on other GPUs, the dma address array
has been populated in amdgpu_ttm_backend_bind.
OK. I think "has been populated" should be "will be populated", because
amdgpu_ttm_backend_bind happens as a callback from the ttm_bo_validate
Am 2023-04-04 um 05:56 schrieb Shane Xiao:
For SG BO to DMA-map userptrs on other GPUs, the SG BO need inherit
MTYPEs in PTEs from original BO.
Good catch. See two comments inline.
If we set the flags, the device can be coherent with the CPUs and other GPUs.
Signed-off-by: Shane Xiao
---
[+Philip]
Am 2023-04-04 um 08:47 schrieb Christian König:
Am 04.04.23 um 12:56 schrieb Xiao, Shane:
[AMD Official Use Only - General]
-Original Message-
From: Koenig, Christian
Sent: Tuesday, April 4, 2023 6:27 PM
To: Xiao, Shane ; amd-gfx@lists.freedesktop.org;
Kuehling, Felix
[AMD Official Use Only - General]
Comments inline
> -Original Message-
> From: amd-gfx On Behalf Of
> Sreekant Somasekharan
> Sent: Monday, April 3, 2023 3:59 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Somasekharan, Sreekant
> Subject: [PATCH] drm/amdkfd: On GFX11 check PCIe atomics
Am 04.04.23 um 12:56 schrieb Xiao, Shane:
[AMD Official Use Only - General]
-Original Message-
From: Koenig, Christian
Sent: Tuesday, April 4, 2023 6:27 PM
To: Xiao, Shane ; amd-gfx@lists.freedesktop.org;
Kuehling, Felix
Cc: Liu, Aaron ; Guo, Shikai
Subject: Re: [PATCH 1/3]
[AMD Official Use Only - General]
> -Original Message-
> From: Koenig, Christian
> Sent: Tuesday, April 4, 2023 6:27 PM
> To: Xiao, Shane ; amd-gfx@lists.freedesktop.org;
> Kuehling, Felix
> Cc: Liu, Aaron ; Guo, Shikai
> Subject: Re: [PATCH 1/3] drm/amdgpu: Add userptr bo support
Hi,
On 03/04/2023 20:40, Joshua Ashton wrote:
Hello all!
I would like to propose a new API for allowing processes to control
the priority of GPU queues similar to RLIMIT_NICE/RLIMIT_RTPRIO.
The main reason for this is for compositors such as Gamescope and
SteamVR vrcompositor to be able to
On Fri, Mar 24, 2023 at 7:37 PM Christian König
wrote:
>
> Yeah, that one
>
> Thanks for the info, looks like this isn't fixed.
>
> Christian.
>
Hi,
glad to see that "BUG: KASAN: slab-use-after-free in
drm_sched_get_cleanup_job+0x47b/0x5c0" was fixed in 6.3-rc5.
For history it would be good to
Am 04.04.23 um 11:56 schrieb Shane Xiao:
For userptr bo with iommu on, multiple GPUs use same system
memory dma mapping address when both bo_adev and adev in identity
mode or in the same iommu group.
WTF? Userptr BOs are not allowed to be exported/imported between
different GPUs.
So how can
For DMA-MAP userptr on other GPUs, the dma address array
has been populated in amdgpu_ttm_backend_bind.
Remove the redundant call from the driver.
Signed-off-by: Shane Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
For SG BO to DMA-map userptrs on other GPUs, the SG BO need inherit
MTYPEs in PTEs from original BO.
If we set the flags, the device can be coherent with the CPUs and other GPUs.
Signed-off-by: Shane Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 10 +-
1 file changed, 9
For userptr bo with iommu on, multiple GPUs use same system
memory dma mapping address when both bo_adev and adev in identity
mode or in the same iommu group.
Signed-off-by: Shane Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
1 file changed, 4 insertions(+), 4
Adding a bunch of people who have been involved in this before.
Am 03.04.23 um 22:15 schrieb Joshua Ashton:
On 4/3/23 20:54, Christian König wrote:
Am 03.04.23 um 21:40 schrieb Joshua Ashton:
[SNIP]
Anyway, please let me know what you think!
Definitely open to any feedback and advice you may
Hello Alvin Lee,
This is a semi-automatic email about new static checker warnings.
The patch 4ed793083afc: "drm/amd/display: Use per pipe P-State force
for FPO" from Mar 15, 2023, leads to the following Smatch complaint:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:2009
There are several calls to ci_dpm_fini() in ci_dpm_init() when there
occur errors in functions like r600_parse_extended_power_table().
This is harmful as it can lead to double free situations: for
instance, r600_parse_extended_power_table() will call for
r600_free_extended_power_table() as will
The adev->dm.dc pointer can be NULL and dereferenced in amdgpu_dm_fini()
without checking.
Add a NULL pointer check before calling dc_dmub_srv_destroy().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 9a71c7d31734 ("drm/amd/display: Register DMUB service with DC")
37 matches
Mail list logo
