Encountering a taint issue during the unloading of gpu_sched
due to the fence not being released/put. In this context,
amdgpu_vm_clear_freed is responsible for creating a job to
update the page table (PT). It allocates kmem_cache for
drm_sched_fence and returns the finished fence associated
with jo
ping on this series.
Alex
On Wed, Feb 26, 2025 at 11:09 PM Alex Deucher wrote:
>
> Just use the default values. There's not need to
> get the value from hardware and it could cause problems
> if we do that at runtime and gfxoff is active.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/dr
Applied with a small tweak to fix a warning.
Thanks,
Alex
On Mon, Mar 3, 2025 at 7:55 AM Marek Olšák wrote:
>
> Reviewed-by: Marek Olšák
>
> On Tue, Jun 18, 2019 at 3:19 AM Richard Thier wrote:
>>
>> num_gb_pipes was set to a wrong value using r420_pipe_config
>>
>> This have lead to HyperZ g
Applied the series. Thanks!
Alex
On Mon, Mar 3, 2025 at 9:49 AM wrote:
>
> From: "Dr. David Alan Gilbert"
>
> pqm_get_kernel_queue() has been unused since 2022's
> commit 5bdd3eb25354 ("drm/amdkfd: Remove unused old debugger
> implementation")
>
> Remove it.
>
> Signed-off-by: Dr. David Alan G
Reviewed-by: Alex Hung
On 2/28/25 11:51, Mario Limonciello wrote:
As new members are introduced to the structure copying the entire
structure will help avoid missing them.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 6 +-
1 file changed, 1 insertion(
On Fri, Feb 21, 2025 at 8:38 AM Prike Liang wrote:
>
> Implement the kernel graphics queue pipe reset,and the driver
> will fallback to pipe reset when the queue reset fails. However,
> the ME FW hasn't fully supported pipe reset yet so disable the
> KGQ pipe reset temporarily.
>
> Signed-off-by:
[AMD Official Use Only - AMD Internal Distribution Only]
The series is:
Reviewed-by: Leo Liu
> -Original Message-
> From: Sundararaju, Sathishkumar
> Sent: February 26, 2025 11:51 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Leo ; Sundararaju, Sathishkumar
>
> Subject: [PATCH 2/2]
On Mon, Mar 3, 2025 at 7:09 AM Liang, Prike wrote:
>
> [Public]
>
> Question: Why use the CONFIG_DRM_AMDGPU_NAVI3X_USERQ to guard all the various
> GFX user mode queue enablement paths? It seems more generic and reasonable to
> use the config name CONFIG_DRM_AMDGPU_NAVI3X_USERQ.
>
I assume you
[AMD Official Use Only - AMD Internal Distribution Only]
Ping
-Original Message-
From: Xiaogang.Chen
Sent: Friday, January 31, 2025 10:59 AM
To: amd-gfx@lists.freedesktop.org
Cc: Chen, Xiaogang
Subject: [PATCH] drm/amdkfd: Change error handling at prange update in
svm_range_set_attr
F
Applied. Thanks.
Alex
On Fri, Feb 28, 2025 at 11:19 PM Alexandre Demers
wrote:
>
> DCE6 was missing soft reset, but it was easily identifiable under radeon.
> This should be it, pretty much as it is done under DCE8 and DCE10.
>
> Signed-off-by: Alexandre Demers
> ---
> drivers/gpu/drm/amd/amd
Applied these. thanks.
Alex
On Fri, Feb 28, 2025 at 9:22 PM Alexandre Demers
wrote:
>
> While going throught DCE6 code, I took on myself to add some comments
> and to fix style in a few places.
>
> Alexandre Demers (2):
> drm/amdgpu: add some comments in DCE6
> dmr/amdgpu: fix style in DCE6
On Fri, Feb 28, 2025 at 11:11 PM Alexandre Demers
wrote:
>
> dce_v6_0_set_crtc_vline_interrupt_state() was empty without any info to
> inform the user.
I don't see much point in adding this. As I mentioned previously,
this interrupt source is never used. Would be better to just remove
it.
Alex
[Public]
Thank you for the input. I have confirmed with the firmware team that the CP FW
_start instruction address will be kept consistent.
Could we move this patch series forward now?
Regards,
Prike
> -Original Message-
> From: Alex Deucher
> Sent: Thursday, February 27, 2025 1
For equal case, it also need to be dropped.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
index 7d4395a5d8ac..73b8bcb54734 1
drm_* macros are more helpful that DRM_* macros since the former
indicates the associated DRM device that prints the error, which maybe
helpful when debugging.
Signed-off-by: Aurabindo Pillai
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+
Implement w/a for a panel which requires 10s delay after link detect.
Signed-off-by: Aurabindo Pillai
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 10 ++--
drivers/gpu/drm/amd/display/dc/dc_types.h | 1 +
3 f
Hi Raag,
On 2/28/25 11:58, Raag Jadav wrote:
On Fri, Feb 28, 2025 at 09:13:53AM -0300, André Almeida wrote:
To notify userspace about which app (if any) made the device get in a
wedge state, make use of drm_wedge_app_info parameter, filling it with
the app PID and name.
Signed-off-by: André Al
On Fri, Feb 28, 2025 at 09:13:53AM -0300, André Almeida wrote:
> To notify userspace about which app (if any) made the device get in a
> wedge state, make use of drm_wedge_app_info parameter, filling it with
> the app PID and name.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/amd/amd
On 28.02.25 17:36, Markus Elfring wrote:
From: Markus Elfring
Date: Fri, 28 Feb 2025 17:32:45 +0100
Replace nested max() calls by single max3() call in this
function implementation.
This issue was transformed by using the Coccinelle software.
How about something like "this change was made" o
From: Markus Elfring
Date: Fri, 28 Feb 2025 16:37:00 +0100
Replace nested max() calls by single max3() call in this
function implementation.
This issue was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/amdgpu/si.c | 2 +-
1 file changed, 1
On Fri, Feb 28, 2025 at 06:54:12PM -0300, André Almeida wrote:
> Hi Raag,
>
> On 2/28/25 11:20, Raag Jadav wrote:
> > Cc: Lucas
> >
> > On Fri, Feb 28, 2025 at 09:13:52AM -0300, André Almeida wrote:
> > > When a device get wedged, it might be caused by a guilty application.
> > > For userspace, k
Hi Raag,
On 2/28/25 11:20, Raag Jadav wrote:
Cc: Lucas
On Fri, Feb 28, 2025 at 09:13:52AM -0300, André Almeida wrote:
When a device get wedged, it might be caused by a guilty application.
For userspace, knowing which app was the cause can be useful for some
situations, like for implementing a
On Fri, Feb 28, 2025 at 06:49:43PM -0300, André Almeida wrote:
> Hi Raag,
>
> On 2/28/25 11:58, Raag Jadav wrote:
> > On Fri, Feb 28, 2025 at 09:13:53AM -0300, André Almeida wrote:
> > > To notify userspace about which app (if any) made the device get in a
> > > wedge state, make use of drm_wedge_
Reviewed-by: Marek Olšák
On Tue, Jun 18, 2019 at 3:19 AM Richard Thier wrote:
> num_gb_pipes was set to a wrong value using r420_pipe_config
>
> This have lead to HyperZ glitches on fast Z clearing.
>
> See: https://bugs.freedesktop.org/show_bug.cgi?id=110897
>
> Signed-off-by: Richard Thier
>
[Public]
Question: Why use the CONFIG_DRM_AMDGPU_NAVI3X_USERQ to guard all the various
GFX user mode queue enablement paths? It seems more generic and reasonable to
use the config name CONFIG_DRM_AMDGPU_NAVI3X_USERQ.
Except for that question, the series patch is Reviewed-by: Prike Liang
.
Re
From: Markus Elfring
Date: Fri, 28 Feb 2025 17:32:45 +0100
Replace nested max() calls by single max3() call in this
function implementation.
This issue was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
1 file change
Cc: Lucas
On Fri, Feb 28, 2025 at 09:13:52AM -0300, André Almeida wrote:
> When a device get wedged, it might be caused by a guilty application.
> For userspace, knowing which app was the cause can be useful for some
> situations, like for implementing a policy, logs or for giving a chance
> for t
Dequeue retry timeout controls the interval between checks for unmet
conditions. On MI series, reduce this from 0x40 to 0x1 (~ 1 uS). The
cost of additional bandwidth consumed by CP when polling memory
shouldn't be substantial.
Signed-off-by: Harish Kasiviswanathan
Reviewed-by: : Jonathan Kim
--
Update pm_update_grace_period() to more cleaner
pm_config_dequeue_wait_counts(). Previously, grace_period variable was
overloaded as a variable and a macro, making it inflexible to configure
additional dequeue wait times.
pm_config_dequeue_wait_counts() now takes in a cmd / variable. This
allows f
[Public]
> -Original Message-
> From: Kasiviswanathan, Harish
> Sent: Monday, March 3, 2025 3:44 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Kasiviswanathan, Harish ; Kim, Jonathan
>
> Subject: [PATCH v2 2/2] drm/amdgpu: Reduce dequeue retry timeout for gfx9
> family
>
> Dequeue retry
On 2025-03-03 13:48, Christian König wrote:
> Am 03.03.25 um 19:45 schrieb James Zhu:
>> before move to GTT domain.
> That might not be unnecessary. We sometimes intentionally move BOs to the CPU
> domain to invalidate all VM mappings.
We discussed this in our VM sync meeting this morning, and I
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Harish
> Kasiviswanathan
> Sent: Wednesday, February 26, 2025 2:23 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Kasiviswanathan, Harish
> Subject: [PATCH 2/2] drm/amdgpu: Reduce dequeue retry timeout for gfx9 family
>
> Dequeue r
[AMD Official Use Only - AMD Internal Distribution Only]
Ping..
Emily Deng
Best Wishes
>-Original Message-
>From: Emily Deng
>Sent: Monday, March 3, 2025 5:35 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deng, Emily
>Subject: [PATCH] drm/amdgpu: Fix missing drain retry fault the la
[AMD Official Use Only - AMD Internal Distribution Only]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
From: Yi, Tony
Sent: Friday, February 28, 2025 22:01
To: Zhang, Hawking ; Skvortsov, Victor
; amd-gfx@lists.freedesktop.org; Luo, Zhigang
; Liu, Xiang(Dean) ; Zhou1, Tao
Subject:
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Harish
> Kasiviswanathan
> Sent: Monday, March 3, 2025 3:44 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Kasiviswanathan, Harish
> Subject: [PATCH v2 1/2] drm/amdkfd: Add pm_config_dequeue_wait_counts API
>
> Update pm_update_gra
Describes what debugfs files are available and what
they are used for.
Signed-off-by: Alex Deucher
---
Documentation/gpu/amdgpu/debugfs.rst | 201 +++
Documentation/gpu/amdgpu/index.rst | 1 +
2 files changed, 202 insertions(+)
create mode 100644 Documentation/gpu/am
[Public]
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, March 4, 2025 12:15 AM
> To: Liang, Prike
> Cc: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 5/5] drm/amdgpu/userq: remove BROKEN from config
>
> On Mon, Mar 3, 2025 at 7:09 AM Liang, Prike wro
This has conflicts to latest asdn and a minor spacing issue below.
The others look good to me.
Reviewed-by: Alex Hung
On 3/3/25 06:50, Aurabindo Pillai wrote:
Implement w/a for a panel which requires 10s delay after link detect.
Signed-off-by: Aurabindo Pillai
---
.../gpu/drm/amd/display/
Reviewed-by: Alex Hung
On 3/3/25 06:50, Aurabindo Pillai wrote:
drm_* macros are more helpful that DRM_* macros since the former
indicates the associated DRM device that prints the error, which maybe
helpful when debugging.
Signed-off-by: Aurabindo Pillai
---
drivers/gpu/drm/amd/display/amd
[Public]
-Original Message-
From: Kim, Jonathan
Sent: Monday, March 3, 2025 3:54 PM
To: Kasiviswanathan, Harish ;
amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH v2 2/2] drm/amdgpu: Reduce dequeue retry timeout for gfx9
family
[Public]
> -Original Message-
> From: Kasiviswan
[AMD Official Use Only - AMD Internal Distribution Only]
Thanks Alex, I'll fix that and push.
--
Regards,
Jay
From: Hung, Alex
Sent: Monday, March 3, 2025 4:48 PM
To: Pillai, Aurabindo ; amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; Li, Sun peng (Leo)
On 2025-01-31 11:58, Xiaogang.Chen wrote:
> From: Xiaogang Chen
>
> When register a vm range at svm the added vm range may be split into multiple
> subranges and/or existing pranges got spitted. The new pranges need validated
> and mapped. This patch changes error handling for pranges that fail
[AMD Official Use Only - AMD Internal Distribution Only]
Ping on this series?
-Original Message-
From: jesse.zh...@amd.com
Sent: Friday, February 28, 2025 6:27 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Lazar, Lijo ; Zhu, Jiadong
; Zhang, Jesse(Ji
On 3/4/2025 1:49 PM, Felix Kuehling wrote:
> On 2025-02-21 4:23, Zhu Lingshan wrote:
>> This commit initialized svm lists at where they are
>> defined. This is defensive programing for security
>> and consistency.
>>
>> Initalizing variables ensures that their states are
>> always valid, avoiding i
On 2025-02-21 4:23, Zhu Lingshan wrote:
> This commit initialized svm lists at where they are
> defined. This is defensive programing for security
> and consistency.
>
> Initalizing variables ensures that their states are
> always valid, avoiding issues caused by
> uninitialized variables that coul
On 2/28/2025 3:57 PM, jesse.zh...@amd.com wrote:
> From: "jesse.zh...@amd.com"
>
> - Modify the VM invalidation engine allocation logic to handle SDMA page
> rings.
> SDMA page rings now share the VM invalidation engine with SDMA gfx rings
> instead of
> allocating a separate engine. Thi
On 2025-01-31 11:58, Xiaogang.Chen wrote:
> From: Xiaogang Chen
>
> When register a vm range at svm the added vm range may be split into multiple
> subranges and/or existing pranges got spitted. The new pranges need validated
> and mapped. This patch changes error handling for pranges that fail
before move to GTT domain.
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 62ca12e94581..2ac6d4fa0601
Am 03.03.25 um 19:45 schrieb James Zhu:
> before move to GTT domain.
That might not be unnecessary. We sometimes intentionally move BOs to the CPU
domain to invalidate all VM mappings.
Christian.
>
> Signed-off-by: James Zhu
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 --
50 matches
Mail list logo
