An issue was identified in the dcn21_link_encoder_create function where
an out-of-bounds access could occur when the hpd_source index was used
to reference the link_enc_hpd_regs array. This array has a fixed size
and the index was not being checked against the array's bounds before
accessing it.
T
Am 20.09.24 um 09:36 schrieb YiPeng Chai:
In multiple GPUs case, after a GPU has started
resetting all GPUs on hive, other GPUs do not
need to trigger GPU reset again.
Please drop any such handling. GPU resets in a hive are serialized using
a single thread workqueue.
If you want to prevent m
On 2024/9/20 02:58, Thomas Zimmermann wrote:
Hi
Am 19.09.24 um 20:28 schrieb WangYuli:
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
Signed-off-by: WangYuli
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx
在 2024/9/20 03:01, Christian König wrote:
Am 19.09.24 um 20:28 schrieb WangYuli:
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
Signed-off-by: WangYuli
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_4
On Thu, 19 Sep 2024, Fangzhi Zuo wrote:
> [why]
> How we determine the dsc_aux used for dsc decompression in
> drm_dp_mst_dsc_aux_for_port() today having some defects:
>
> 1. The method how we determine a connected peer device is virtual or not
>in drm_dp_mst_is_virtual_dpcd() is not always co
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
And the comment style should be like this:
/*
* Text
* Text
*/
Suggested-by: Christian König
Link: https://lore.kernel.org/all/f75fbe30-528e-404f-97e4-854d27d7a...@amd.com/
Acked-by: Thomas Zimm
Recent kernels resulted in a blank screen, with Xorg.0.log reporting:
(II) [KMS] drm report modesetting isn't supported.
Sometimes while bisecting the pc came to a complete lockup (magic Sysreq
unresponsive).
At the end of bisecting I had:
90985660ba488cd3428706e7d53d6c9cdbbf3101 is the first
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
Signed-off-by: WangYuli
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 2 +-
drivers/leds/rgb/leds-group-multicolor.c | 2 +-
3 files changed, 3 inserti
Giving the opportunity to userspace to associate a free-form
name with a drm_file struct is helpful for tracking and debugging.
This is similar to the existing DMA_BUF_SET_NAME ioctl.
Access to name is protected by a mutex, and the 'clients' debugfs
file has been updated to print it.
Userspace M
This will allow to use flexible array to store the process name and
other information.
This also means that process name will be determined once and for all,
instead of at each submit.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +--
1 f
If a drm_file name is set append it to the process name.
This information is useful with the virtio/native-context driver: this
allows the guest applications identifier to visible in amdgpu's output.
The output in amdgpu_vm_info/amdgpu_gem_info looks like this:
pid:12255Process:glxgears/te
Add an optional drm-client-name field to drm fdinfo's output.
Reviewed-by: Christian König
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
Documentation/gpu/drm-usage-stats.rst | 5 +
drivers/gpu/drm/drm_file.c| 5 +
2 files changed, 10 insertions(
At this point the vm is locked so we safely modify it without risk of
concurrent access.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/driver
And rename it process_desc, since it will soon contain more than
just the process_name.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
v3 changelog:
* Added DRM_NAME_MAX_LEN instead of using NAME_MAX
* Fixed Tvrtko & Christian comments on patch 1
* Added R-b tags to patch 2
* Following Christian' suggestion patch 3 became 4 patches:
- amdgpu_task_info::process_name is now a flexible array
- amdgpu_vm::task_info is allocated
On Tue, Aug 06, 2024 at 10:52:59AM GMT, André Almeida wrote:
> Currently, DRM atomic uAPI allows only primary planes to be flipped
> asynchronously. However, each driver might be able to perform async
> flips in other different plane types. To enable drivers to set their own
> restrictions on which
Am 20.09.24 um 11:06 schrieb Pierre-Eric Pelloux-Prayer:
If a drm_file name is set append it to the process name.
This information is useful with the virtio/native-context driver: this
allows the guest applications identifier to visible in amdgpu's output.
The output in amdgpu_vm_info/amdgpu_ge
update workload mask after the setting, to fix:
https://gitlab.freedesktop.org/drm/amd/-/issues/3625
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 6 +-
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 3 +++
drivers/gpu/drm/amd/pm/swsmu/smu14/s
Am 20.09.24 um 18:31 schrieb Dipendra Khadka:
On Fri, 20 Sept 2024 at 16:01, Christian König wrote:
Am 20.09.24 um 11:09 schrieb Dipendra Khadka:
'''
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c:108:9: error: Null pointer
dereference: fence [nullPointer]
return fence->timeline_name;
On 17/09/2024 15:21, Alex Deucher wrote:
On Mon, Aug 12, 2024 at 2:10 AM Lu Yao wrote:
Add support for the drm_panic module, which displays a pretty user
friendly message on the screen when a Linux kernel panic occurs.
Signed-off-by: Lu Yao
Patch looks good to me. Any chance you want to c
program SDMAx_QUEUEx_SCHEDULE_CNTL for context switch due to
quantum in KFD for GFX12.
Signed-off-by: Sreekant Somasekharan
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v12.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v12.c
b/drivers/gpu
Currently, the code use the IH_VMID_X_LUT register to map
a queue's vmid to the corresponding PASID. This logic is racy
since the CP can update the VMID-PASID mapping anytime especially
when there are more processes than number of vmids. Update the logic
to calculate CU occupancy by matching doorbe
Make CU occupancy calculations work on GFX 9.4.3 by
updating the logic to handle multiple XCCs correctly.
Signed-off-by: Mukul Joshi
---
v1->v2:
- Break into 2 patches, one for the generic change
and the other for GFX v9.4.3.
- Incorporate Harish's comments.
drivers/gpu/drm/amd/amdgpu/amdgpu_
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Harish Kasiviswanathan
-Original Message-
From: amd-gfx On Behalf Of Sreekant
Somasekharan
Sent: Friday, September 20, 2024 12:14 PM
To: amd-gfx@lists.freedesktop.org
Cc: Somasekharan, Sreekant
Subject: [PATCH] drm/
On 2024-09-20 01:56, Jani Nikula wrote:
> On Thu, 19 Sep 2024, Fangzhi Zuo wrote:
>> [why]
>> How we determine the dsc_aux used for dsc decompression in
>> drm_dp_mst_dsc_aux_for_port() today having some defects:
>>
>> 1. The method how we determine a connected peer device is virtual or not
>>
Am 20.09.24 um 11:09 schrieb Dipendra Khadka:
'''
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c:108:9: error: Null pointer
dereference: fence [nullPointer]
return fence->timeline_name;
^
'''
The method to_amdgpu_amdkfd_fence can return NULL incase of empty f
or f->ops != &amdkfd_f
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Chai, Thomas
Sent: Friday, September 20, 2024 15:36
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Zhou1, Tao ; Li,
Candice ; Wang, Yang(Kevin) ; Yang,
In multiple GPUs case, after a GPU has started
resetting all GPUs on hive, other GPUs do not
need to trigger GPU reset again.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/g
The guilty handling tried to establish a second way of signaling problems with
the GPU back to userspace. This caused quite a bunch of issue we had to work
around, especially lifetime issues with the drm_sched_entity.
Just drop the handling altogether and use the dma_fence based approach instead.
[AMD Official Use Only - AMD Internal Distribution Only]
Hi all,
This week this patchset was tested on 4 systems, two dGPU and two APU based,
and tested across multiple display and connection types.
APU
* Single Display eDP -> 1080p 60hz, 2560x1600 120hz, 1920x1200 165hz
* Singl
30 matches
Mail list logo