[AMD Official Use Only - AMD Internal Distribution Only]
Hi Philipp,
I updated the commit message to better clarify the issue. Would you mind
reviewing if this revised description adequately explains the bug and the
rationale behind the fix?
When an entity from application B is killed, drm_sch
ISP is a child device to GFX, and its device specific information
is not available in ACPI. Adding the 2 GPIO resources required for
ISP_v4_1_1 in amdgpu_isp driver.
- GPIO 0 to allow sensor driver to enable and disable sensor module.
- GPIO 85 to allow ISP driver to enable and disable ISP RGB str
Hi Mario,
On 5/15/2025 4:05 PM, Mario Limonciello wrote:
On 5/15/2025 2:54 PM, Pratap Nirujogi wrote:
ISP is a child device to GFX, and its device specific information
is not available in ACPI. Adding the 2 GPIO resources required for
ISP_v4_1_1 in amdgpu_isp driver.
- GPIO 0 to allow sensor d
On 5/15/2025 3:45 PM, Philip Yang wrote:
On 2025-05-15 10:29, Chen, Xiaogang wrote:
Does this patch fix a bug or just make code look more reasonable?
kfd_process_destroy_pdds releases pdd related buffers, not related to
operations on vm. So vm tear down dose not affect this function.
Thi
On 2025-05-15 10:29, Chen, Xiaogang wrote:
Does this patch fix a bug or just make code look more reasonable?
kfd_process_destroy_pdds releases pdd related buffers, not related to
operations on vm. So vm tear down dose not affect this function.
This change doesn't fix anything currently, as
On 5/15/2025 2:54 PM, Pratap Nirujogi wrote:
ISP is a child device to GFX, and its device specific information
is not available in ACPI. Adding the 2 GPIO resources required for
ISP_v4_1_1 in amdgpu_isp driver.
- GPIO 0 to allow sensor driver to enable and disable sensor module.
- GPIO 85 to all
ISP is a child device to GFX, and its device specific information
is not available in ACPI. Adding the 2 GPIO resources required for
ISP_v4_1_1 in amdgpu_isp driver.
- GPIO 0 to allow sensor driver to enable and disable sensor module.
- GPIO 85 to allow ISP driver to enable and disable ISP RGB str
On 2025-05-15 10:40, Chen, Xiaogang wrote:
On 5/14/2025 12:10 PM, Philip Yang wrote:
Move vm root bo unreserve after vm->va mapping free because we should
hold vm lock to access vm->va.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
1 file changed, 4
On 2025-05-15 13:19, Daniel Stone wrote:
> Hi,
>
> On Thu, 15 May 2025 at 15:11, Harry Wentland wrote:
>> On 2025-05-15 05:45, Simon Ser wrote:
>>> I've reviewed all of the core DRM patches :)
>>>
>>> Have there been updates from user-space implementations?
>>
>> I know Leandro has been workin
On 5/15/2025 2:06 PM, Alex Deucher wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Thu, May 15, 2025 at 2:03 PM Mario Limonciello
wrote:
On 5/15/2025 12:47 PM, Nirujogi, Pratap wrote:
Hi Mari
Hi,
On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> On 2025-05-15 13:19, Daniel Stone wrote:
> > Yeah, the Weston patches are marching on. We've still been doing a
> > little bit of cleanup and prep work in the background to land them,
> > but we also can't land them until the kernel lands.
On 5/15/2025 12:47 PM, Nirujogi, Pratap wrote:
Hi Mario,
On 5/14/2025 6:05 PM, Mario Limonciello wrote:
On 5/14/2025 4:35 PM, Pratap Nirujogi wrote:
ISP is a child device to GFX, and its device specific information
is not available in ACPI. Adding the 2 GPIO resources required for
ISP_v4_1_1 i
On Thu, May 15, 2025 at 2:03 PM Mario Limonciello
wrote:
>
> On 5/15/2025 12:47 PM, Nirujogi, Pratap wrote:
> > Hi Mario,
> >
> > On 5/14/2025 6:05 PM, Mario Limonciello wrote:
> >> On 5/14/2025 4:35 PM, Pratap Nirujogi wrote:
> >>> ISP is a child device to GFX, and its device specific information
Hi Steven,
thanks for the bisect.
In order to avoid display artifacts (especially for HDR) we had to
allow higher bit depth color output on the wire. The driver should
fallback to a lower resolution as needed but looks like there's a
bug with this particular TV. Are you able to share the specific
[AMD Official Use Only - AMD Internal Distribution Only]
With the change,
The series is
Reviewed-by: Ruijing Dong
Thanks,
Ruijing
-Original Message-
From: Wu, David
Sent: Thursday, May 15, 2025 1:30 PM
To: Dong, Ruijing ; Wu, David ;
amd-gfx@lists.freedesktop.org; Koenig, Christian
Hi Mario,
On 5/14/2025 6:05 PM, Mario Limonciello wrote:
On 5/14/2025 4:35 PM, Pratap Nirujogi wrote:
ISP is a child device to GFX, and its device specific information
is not available in ACPI. Adding the 2 GPIO resources required for
ISP_v4_1_1 in amdgpu_isp driver.
- GPIO 0 to allow sensor d
The addition of register read-back in VCN v5.0.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
b
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Wu, David
Sent: Thursday, May 15, 2025 12:41 PM
To: amd-gfx@lists.freedesktop.org; Koenig, Christian
Cc: Deucher, Alexander ; Liu, Leo ;
Jiang, Sonny ; Dong, Ruijing
Subject: [PATCH v2 5/9] drm/amdgpu: re
The addition of register read-back in VCN v4.0.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/dri
On 2025-05-15 13:25, Dong, Ruijing wrote:
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Wu, David
Sent: Thursday, May 15, 2025 12:41 PM
To: amd-gfx@lists.freedesktop.org; Koenig, Christian
Cc: Deucher, Alexander ; Liu, Leo ; Jiang,
Sonny ; Dong, R
Hi,
On Thu, 15 May 2025 at 15:11, Harry Wentland wrote:
> On 2025-05-15 05:45, Simon Ser wrote:
> > I've reviewed all of the core DRM patches :)
> >
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver
The addition of register read-back in VCN v2.5 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
b/driver
The addition of register read-back in VCN v3.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
b/drive
The addition of register read-back in VCN v5.0.1 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v5_0_1.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdg
V2: use common register UVD_STATUS for readback (standard PCI MMIO
behavior, i.e. readback post all writes to let the writes hit
the hardware)
add read-back in ..._stop() for more coverage.
Similar to the changes made for VCN v4.0.5 where readback to post the
writes to avoid race with
The addition of register read-back in VCN v4.0.5 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/am
The addition of register read-back in VCN v4.0.3 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
b/dri
The addition of register read-back in VCN v2.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
b/driv
On 15/05/2025 16:00, Christian König wrote:
Sometimes drivers need to be able to submit multiple jobs which depend on
each other to different schedulers at the same time, but using
drm_sched_job_add_dependency() can't fail any more after the first job is
initialized.
This function preallocate
+ Harry
On Thu, May 15, 2025 at 12:11 PM Steven J Abner wrote:
>
> On Mon, May 12 2025 at 08:10:40 PM +, Alex Deucher
> wrote:
> > See:
> > https://docs.kernel.org/admin-guide/bug-bisect.html
> > ... identify the exact commit which broke caused your issue.
>
> One heck of a journey! But tes
On 5/12/2025 12:41 PM, Paneer Selvam, Arunpravin wrote:
On 5/12/2025 12:39 PM, Christian König wrote:
On 5/11/25 22:37, Paneer Selvam, Arunpravin wrote:
On 5/12/2025 2:03 AM, Paneer Selvam, Arunpravin wrote:
On 5/3/2025 5:53 PM, Paneer Selvam, Arunpravin wrote:
On 5/2/2025 9:02 PM, J
Sometimes drivers need to be able to submit multiple jobs which depend on
each other to different schedulers at the same time, but using
drm_sched_job_add_dependency() can't fail any more after the first job is
initialized.
This function preallocate memory for dependency slots so that no ENOMEM
ca
Just to exercise the functionality.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/tests/tests_basic.c | 59 ++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/tests/tests_basic.c
b/drivers/gpu/drm/scheduler/tests/tests_basi
Hi Tvrtko,
On Thu, May 15, 2025 at 10:50:03AM +0100, Tvrtko Ursulin wrote:
> Protect the access to driver and timeline name which otherwise could be
> freed as dma-fence exported is signalling fences.
>
> Now that the safe access is handled in the dma-fence API, the external
> callers such as syn
For the unlikely case that we ran into an ENOMEM while fixing up the gang
submission dependencies we can't clean up any more since the gang
members are already armed.
Fix this by using pre-allocated dependency slots and re-ordering the
code, also fix a double unref since the fence reference is als
Hi guys,
third revision of this patch set. I've re-worked the interface
completely this time since my previous assumptions on how the
reservation function of the xarray work weren't correct at all.
I also added a test case to make sure I've got it right this time.
Please review and comment,
Chri
Hi Tvrtko,
On Thu, May 15, 2025 at 10:50:00AM +0100, Tvrtko Ursulin wrote:
> Access the dma-fence internals via the previously added helpers.
>
> Signed-off-by: Tvrtko Ursulin
> Reviewed-by: Christian König
Reviewed-by: Andi Shyti
Thanks,
Andi
On 5/14/2025 12:10 PM, Philip Yang wrote:
Move vm root bo unreserve after vm->va mapping free because we should
hold vm lock to access vm->va.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/d
On Thu, May 15, 2025 at 3:09 AM Rahul Kumar wrote:
>
> Fixes a kernel-doc warning by correctly documenting the enum value
> `DC_HDCP_LC_ENABLE_SW_FALLBACK` in the DC_DEBUG_MASK enum.
>
> The previous documentation was incorrectly formatted and incomplete.
> Updated to follow proper kernel-doc synt
Does this patch fix a bug or just make code look more reasonable?
kfd_process_destroy_pdds releases pdd related buffers, not related to
operations on vm. So vm tear down dose not affect this function.
Regards
Xiaogang
On 5/14/2025 12:10 PM, Philip Yang wrote:
Release pdd->drm_file may free t
On Thursday, May 15th, 2025 at 16:11, Harry Wentland
wrote:
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver had a prototype in kwin.
Cool!
> Ideally we'd have gamescope adopt it and switch off
On 2025-05-15 05:45, Simon Ser wrote:
> I've reviewed all of the core DRM patches :)
>
> Have there been updates from user-space implementations?
I know Leandro has been working on Weston to make use of
this and last year Xaver had a prototype in kwin.
Ideally we'd have gamescope adopt it and
Reviewed-by: Arvind Yadav
On 5/15/2025 6:49 PM, Liang, Prike wrote:
[Public]
[Public]
I haven't cleaned up the userq resource destroy at postclose callback in my
last patch, so here please remove the duplicated useq destroy. With that, the
change in the patch is
Reviewed-by: Prike Liang
R
[Public]
I haven't cleaned up the userq resource destroy at postclose callback in my
last patch, so here please remove the duplicated useq destroy. With that, the
change in the patch is
Reviewed-by: Prike Liang
Regards,
Prike
> -Original Message-
> From: amd-gfx On Behalf Of
>
Hey drm-misc maintainers,
can you guys please backmerge drm-next into drm-misc-next?
I want to push this patch here but it depends on changes which are partially in
drm-next and partially in drm-misc-next.
Thanks in advance,
Christian.
On 5/15/25 11:49, Tvrtko Ursulin wrote:
> With the goal of
On 5/15/25 11:44, Jesse Zhang wrote:
> The original change "drm/amdgpu: promote the implicit sync to the dependent
> read fences"
> (commit 714bbbf20a72) modified fence synchronization to use
> DMA_RESV_USAGE_READ
> instead of DMA_RESV_USAGE_BOOKKEEP. However, the user queue wait ioctl wasn't
>
On 5/14/25 19:10, Philip Yang wrote:
> Move vm root bo unreserve after vm->va mapping free because we should
> hold vm lock to access vm->va.
That should be unnecessary since we are about to destroy the VM.
If anybody is concurrently using it at that point we are completely busted
anyway.
Regar
On 5/15/25 11:24, Prike Liang wrote:
> Lock and refer to the eviction fence before the eviction fence
> schedules work queue tries to signal it.
>
> Suggested-by: Christian König
> Signed-off-by: Prike Liang
> Acked-by: Alex Deucher
> Reviewed-by: Arvind Yadav
Reviewed-by: Christian König
>
On 5/15/25 11:46, Jesse.Zhang wrote:
> The current cleanup order during file descriptor close can lead to
> a race condition where the eviction fence worker attempts to access
> a destroyed mutex from the user queue manager:
>
> [ 517.294055] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
> [ 517.2940
Xe can free some of the data pointed to by the dma-fences it exports. Most
notably the timeline name can get freed if userspace closes the associated
submit queue. At the same time the fence could have been exported to a
third party (for example a sync_fence fd) which will then cause an use-
after-
The original change "drm/amdgpu: promote the implicit sync to the dependent
read fences"
(commit 714bbbf20a72) modified fence synchronization to use DMA_RESV_USAGE_READ
instead of DMA_RESV_USAGE_BOOKKEEP. However, the user queue wait ioctl wasn't
fully
updated to account for this change, leading
The current cleanup order during file descriptor close can lead to
a race condition where the eviction fence worker attempts to access
a destroyed mutex from the user queue manager:
[ 517.294055] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 517.294060] WARNING: CPU: 8 PID: 2030 at kernel/locking/m
Dma-fence objects currently suffer from a potential use after free problem
where fences exported to userspace and other drivers can outlive the
exporting driver, or the associated data structures.
The discussion on how to address this concluded that adding reference
counting to all the involved ob
Protect the access to driver and timeline name which otherwise could be
freed as dma-fence exported is signalling fences.
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/sync_file.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_fil
Protect the access to driver and timeline name which otherwise could be
freed as dma-fence exported is signalling fences.
Now that the safe access is handled in the dma-fence API, the external
callers such as sync_file, and our internal code paths, we can drop the
similar protection from i915_fenc
Access the dma-fence internals via the previously added helpers.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 4 ++--
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence.c| 4 ++--
3 files
With the goal of reducing the need for drivers to touch (and dereference)
fence->ops, we move the 64-bit seqnos flag from struct dma_fence_ops to
the fence->flags.
Drivers which were setting this flag are changed to use new
dma_fence_init64() instead of dma_fence_init().
v2:
* Streamlined init a
Hi all,
tl;dr;
Xe and probably some other drivers can tear down the internal state referenced
by an exported sync_file fence which then causes a null pointer derefences on
accessing said fence.
IGT that exploits the problem:
https://patchwork.freedesktop.org/patch/642709/?series=146211&rev=2
It
With the goal of reducing the need for drivers to touch (and dereference)
fence->ops, we change the prototype of __dma_fence_is_later() to take
fence instead of fence->ops.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 2 +-
drivers/dma-buf/
Access the dma-fence internals via the previously added helpers.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
---
drivers/dma-buf/sync_file.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index
Add some helpers in order to enable preventing dma-fence users accessing
the implementation details directly and make the implementation itself use
them.
This will also enable later adding some asserts to a consolidated
location.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
---
d
I've reviewed all of the core DRM patches :)
Have there been updates from user-space implementations?
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Lock and refer to the eviction fence before the eviction fence
schedules work queue tries to signal it.
Suggested-by: Christian König
Signed-off-by: Prike Liang
Acked-by: Alex Deucher
Reviewed-by: Arvind Yadav
---
drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c | 11 ++-
1 file cha
Reviewed-by: Simon Ser
[AMD Official Use Only - AMD Internal Distribution Only]
The series is:
Reviewed-by: Tao Zhou
Regrading "enum amdgpu_vcn_v4_0_3_sub_block" and "enum
amdgpu_jpeg_v4_0_3_sub_block", we can unify them for VCN versions in the future.
> -Original Message-
> From: amd-gfx On Behalf Of
> St
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Sunil Khatri
-Original Message-
From: Koenig, Christian
Sent: Thursday, May 15, 2025 2:30 PM
To: Yadav, Arvind ; Deucher, Alexander
; Khatri, Sunil
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu:
On 5/15/25 09:49, Arvind Yadav wrote:
> The eviction fence destroy path incorrectly calls dma_fence_put() on
> evf_mgr->ev_fence after releasing the ev_fence_lock. This introduces a
> potential use-after-unlock or race because another thread concurrently
> modifies evf_mgr->ev_fence.
>
> Fix this
On 5/15/25 09:06, Jesse.Zhang wrote:
> The current cleanup order during file descriptor close can lead to
> a race condition where the eviction fence worker attempts to access
> a destroyed mutex from the user queue manager:
>
> [ 517.294055] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
> [ 517.2940
On 5/12/25 04:20, Prike Liang wrote:
> Lock and refer to the eviction fence before the eviction fence
> schedules work queue tries to signal it.
>
> Suggested-by: Christian König
> Signed-off-by: Prike Liang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c | 8 +++-
> 1 file ch
The eviction fence destroy path incorrectly calls dma_fence_put() on
evf_mgr->ev_fence after releasing the ev_fence_lock. This introduces a
potential use-after-unlock or race because another thread concurrently
modifies evf_mgr->ev_fence.
Fix this by grabbing a local reference to evf_mgr->ev_fence
On 5/9/2025 12:03 AM, Alex Deucher wrote:
On Thu, May 8, 2025 at 8:05 AM Christian König
wrote:
Check if the cleaner shader should run directly.
While at it remove amdgpu_vm_need_pipeline_sync(), we also check again
if the VMID has seen a GPU reset since last use and the gds switch
setiing c
Fixes a kernel-doc warning by correctly documenting the enum value
`DC_HDCP_LC_ENABLE_SW_FALLBACK` in the DC_DEBUG_MASK enum.
The previous documentation was incorrectly formatted and incomplete.
Updated to follow proper kernel-doc syntax with a full description.
Verified fix using `make htmldocs`
The current cleanup order during file descriptor close can lead to
a race condition where the eviction fence worker attempts to access
a destroyed mutex from the user queue manager:
[ 517.294055] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 517.294060] WARNING: CPU: 8 PID: 2030 at kernel/locking/m
76 matches
Mail list logo
