[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Zhang, Morris
Sent: Wednesday, May 14, 2025 14:22
To: Zhang, Hawking ; Gao, Likun ;
amd-gfx@lists.freedesktop.org
Subject: [PATCH v3] drm/amdgpu: add debugfs fo
Expose the debugfs file node for user space to dump the IFWI image
on spirom.
For one transaction between PSP and host, it will read out the
images on both active and inactive partitions so a buffer with two
times the size of maximum IFWI image (currently 16MByte) is needed.
v2: move the vbios gf
[AMD Official Use Only - AMD Internal Distribution Only]
[public]
> -Original Message-
> From: Lazar, Lijo
> Sent: Tuesday, May 13, 2025 8:26 PM
> To: Zhang, Morris ; Zhang, Hawking
> ; Gao, Likun ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/amdgpu: add debugfs for s
Register aqua vanjaram jpeg poison irq, add jpeg poison handle.
Signed-off-by: Stanley.Yang
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c | 76
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.h | 7 +++
2 files changed, 83 insertions(+)
diff --git a/d
Register aqua vanjaram vcn poison irq, add vcn poison handle.
Signed-off-by: Stanley.Yang
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 65 +
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.h | 6 +++
2 files changed, 71 insertions(+)
diff --git a/driv
[Public]
Soft ping.
Regards,
Prike
> -Original Message-
> From: Liang, Prike
> Sent: Monday, May 12, 2025 10:20 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Liang, Prike
> ; Koenig, Christian
> Subject: [PATCH v2] drm/amdgpu: lock the eviction fence for wq si
[Public]
Reviewed-by: Alex Deucher
From: Wu, David
Sent: Tuesday, May 13, 2025 6:12 PM
To: amd-gfx@lists.freedesktop.org ; Koenig,
Christian
Cc: Deucher, Alexander ; Liu, Leo ;
Jiang, Sonny ; Dong, Ruijing ;
sta...@vger.kernel.org ; Limonciello, Mario
Subj
V4: add read-back for non-DPG case. This is for protection
purpose as it is not used for producton.
On VCN v4.0.5 there is a race condition where the WPTR is not
updated after starting from idle when doorbell is used. Adding
register read-back after written at function end is to ensure
all reg
On 08/05/2025 08:47, Jani Nikula wrote:
On Tue, 06 May 2025, Melissa Wen wrote:
AMD driver has a function used to compare if two edid are the same; this
is useful to some of the link detection algorithms implemented by
amdgpu. Since the amdgpu function can be helpful for other drivers, this
On 08/05/2025 08:39, Jani Nikula wrote:
On Tue, 06 May 2025, Melissa Wen wrote:
Original drm_edid_get_monitor_name encapsulates raw edid in drm_edid and
then call get_monitor_name. AMD still stores the display name for
debugging, but it is migrating to drm_edid, on the other hand,
drm_dp_mst
Color gamut_remap state log may be not avaiable for some hw versions, so
prevent null pointer dereference by checking if there is a function to
collect data for this hw version.
v2:
- initialize is_gamut_remap_available (Alex H)
Signed-off-by: Melissa Wen
---
.../amd/display/dc/hwss/dcn20/dcn20
On 2025-05-13 17:01, Alex Deucher wrote:
On Tue, May 13, 2025 at 4:33 PM David Wu wrote:
On 2025-05-13 15:29, Alex Deucher wrote:
On Tue, May 13, 2025 at 3:01 PM David Wu wrote:
On 2025-05-13 14:40, Alex Deucher wrote:
On Tue, May 13, 2025 at 2:23 PM David (Ming Qiang) Wu wrote:
V2: no
On Tue, May 13, 2025 at 4:33 PM David Wu wrote:
>
>
> On 2025-05-13 15:29, Alex Deucher wrote:
> > On Tue, May 13, 2025 at 3:01 PM David Wu wrote:
> >>
> >> On 2025-05-13 14:40, Alex Deucher wrote:
> >>
> >> On Tue, May 13, 2025 at 2:23 PM David (Ming Qiang) Wu
> >> wrote:
> >>
> >> V2: not to
On 2025-05-13 11:36, Melissa Wen wrote:
> On 05/13, Pekka Paalanen wrote:
>> On Mon, 12 May 2025 15:50:17 -0300
>> Melissa Wen wrote:
>>
>>> On 04/29, Alex Hung wrote:
Expose one 1D curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB t
On 2025-05-13 15:29, Alex Deucher wrote:
On Tue, May 13, 2025 at 3:01 PM David Wu wrote:
On 2025-05-13 14:40, Alex Deucher wrote:
On Tue, May 13, 2025 at 2:23 PM David (Ming Qiang) Wu wrote:
V2: not to add extra read-back in vcn_v4_0_start and vcn_v5_0_0_start as
there are read-back
On 5/13/2025 2:45 PM, Bjorn Helgaas wrote:
From Denis's report at https://bugzilla.kernel.org/show_bug.cgi?id=220110:
I am having problems with my laptop that has a thunderbolt
controller to which I connected an AMD 6750XT.
The topology of my system is described in this bug:
https://gitlab.fr
>From Denis's report at https://bugzilla.kernel.org/show_bug.cgi?id=220110:
> I am having problems with my laptop that has a thunderbolt
> controller to which I connected an AMD 6750XT.
>
> The topology of my system is described in this bug:
> https://gitlab.freedesktop.org/drm/amd/-/issues/4014
On Tue, May 13, 2025 at 3:01 PM David Wu wrote:
>
>
> On 2025-05-13 14:40, Alex Deucher wrote:
>
> On Tue, May 13, 2025 at 2:23 PM David (Ming Qiang) Wu
> wrote:
>
> V2: not to add extra read-back in vcn_v4_0_start and vcn_v5_0_0_start as
> there are read-back calls already. New comments for
[AMD Official Use Only - AMD Internal Distribution Only]
The series is
Reviewed-by: Ruijing Dong
-Original Message-
From: Wu, David
Sent: Tuesday, May 13, 2025 3:22 PM
To: amd-gfx@lists.freedesktop.org; Koenig, Christian
Cc: Deucher, Alexander ; Liu, Leo ;
Jiang, Sonny ; Dong, Ruijing
V3: patch for VCN v5.0.0 only
Similar to the previous changes made for VCN v4.0.5, the addition of
register read-back support in VCN v5.0.0 is intended to prevent potential
race conditions, even though such issues have not been observed yet.
This change ensures consistency across different VCN var
V3: patch for VCN v4.0.0 only
Similar to the previous changes made for VCN v4.0.5, the addition of
register read-back support in VCN v4.0.0 is intended to prevent potential
race conditions, even though such issues have not been observed yet.
This change ensures consistency across different VCN var
V2: not to add extra read-back in vcn_v4_0_5_start as there is a
read-back already. New comment for better understanding.
On VCN v4.0.5 there is a race condition where the WPTR is not
updated after starting from idle when doorbell is used. The read-back
of regVCN_RB1_DB_CTRL register after wri
On 2025-05-13 14:40, Alex Deucher wrote:
On Tue, May 13, 2025 at 2:23 PM David (Ming Qiang) Wu wrote:
V2: not to add extra read-back in vcn_v4_0_start and vcn_v5_0_0_start as
there are read-back calls already. New comments for better understanding.
Similar to the previous changes made fo
On Tue, May 13, 2025 at 2:23 PM David (Ming Qiang) Wu wrote:
>
> V2: not to add extra read-back in vcn_v4_0_start and vcn_v5_0_0_start as
> there are read-back calls already. New comments for better understanding.
>
> Similar to the previous changes made for VCN v4.0.5, the addition of
> regis
On Tue, May 13, 2025 at 2:23 PM David (Ming Qiang) Wu wrote:
>
> V2: not to add extra read-back in vcn_v4_0_5_start as there is a
> read-back already. New comment for better understanding.
>
> On VCN v4.0.5 there is a race condition where the WPTR is not
> updated after starting from idle when
On 12/05/2025 14:38, Alex Hung wrote:
Hi Melissa,
The patchset looks good to me but there is WIP dcn401 code, meaning
dcn20 and dcn401 are different.
I will check how to refactor code so this patchset can fit better.
I see. Let's wait a bit so.
Anyway, thanks for taking a look.
Melissa
[AMD Official Use Only - AMD Internal Distribution Only]
Hi David,
The last register operation in vcn_v4_0_start and vcn_v5_0_0_start is write, I
guess we can extend this little more to do a dummy read as the last register
operation.
Thanks,
Ruijing
-Original Message-
From: Wu, David
On 13/05/2025 15:27, Alex Hung wrote:
On 4/25/25 14:49, Melissa Wen wrote:
Color gamut_remap state log may be not avaiable for some hw versions, so
prevent null pointer dereference by checking it there is a function to
collect data for this hw version.
Signed-off-by: Melissa Wen
---
...
On 4/25/25 14:49, Melissa Wen wrote:
Color gamut_remap state log may be not avaiable for some hw versions, so
prevent null pointer dereference by checking it there is a function to
collect data for this hw version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/hwss/dcn20/dcn20_hwseq.c
V2: not to add extra read-back in vcn_v4_0_5_start as there is a
read-back already. New comment for better understanding.
On VCN v4.0.5 there is a race condition where the WPTR is not
updated after starting from idle when doorbell is used. The read-back
of regVCN_RB1_DB_CTRL register after wri
V2: not to add extra read-back in vcn_v4_0_start and vcn_v5_0_0_start as
there are read-back calls already. New comments for better understanding.
Similar to the previous changes made for VCN v4.0.5, the addition of
register read-back support in VCN v4.0.0 and v5.0.0 is intended to
prevent pot
On Tue, May 13, 2025 at 1:54 PM Dong, Ruijing wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Then dummy read should not be limited to this register regVCN_RB1_DB_CTRL, it
> can be any valid readable register just for posting the previous write
> operations.
Right. Any
[AMD Official Use Only - AMD Internal Distribution Only]
Then dummy read should not be limited to this register regVCN_RB1_DB_CTRL, it
can be any valid readable register just for posting the previous write
operations.
Thanks,
Ruijing
-Original Message-
From: Wu, David
Sent: Tuesday, M
Reviewed-by: Alex Hung
On 4/22/25 08:58, Melissa Wen wrote:
This reverts commit 272e6aab14bbf98d7a06b2b1cd6308a02d4a10a1.
Applying degamma curve to the cursor by default breaks Linux userspace
expectation.
On Linux, AMD display manager enables cursor degamma ROM just for
implict sRGB on HW ve
On 5/9/2025 4:51 PM, Christian König wrote:
On 5/9/25 12:10, Jesse.Zhang wrote:
This patch resolves a kernel warning that occurs during user queue
initialization:
[ 428.714241] WARNING: CPU: 23 PID: 1965 at drivers/gpu/drm/ttm/ttm_bo.c:823
ttm_bo_validate+0x15c/0x1a0 [ttm]
[ 428.714758]
On Tue, May 13, 2025 at 12:38 PM David (Ming Qiang) Wu
wrote:
>
> Similar to the previous changes made for VCN v4.0.5, the addition of
> register read-back support in VCN v4.0.0 and v5.0.0 is intended to
> prevent potential race conditions, even though such issues have not
> been observed yet. Thi
sounds great! will adjust accordingly.
David
On 2025-05-13 12:44, Alex Deucher wrote:
On Tue, May 13, 2025 at 12:38 PM David (Ming Qiang) Wu
wrote:
On VCN v4.0.5 there is a race condition where the WPTR is not
updated after starting from idle when doorbell is used. The read-back
of regVCN_RB1
On Tue, May 13, 2025 at 12:38 PM David (Ming Qiang) Wu
wrote:
>
> On VCN v4.0.5 there is a race condition where the WPTR is not
> updated after starting from idle when doorbell is used. The read-back
> of regVCN_RB1_DB_CTRL register after written is to ensure the
> doorbell_index is updated before
On 5/13/2025 11:29 AM, David (Ming Qiang) Wu wrote:
Similar to the previous changes made for VCN v4.0.5, the addition of
register read-back support in VCN v4.0.0 and v5.0.0 is intended to
prevent potential race conditions, even though such issues have not
been observed yet. This change ensures co
On 5/13/2025 11:29 AM, David (Ming Qiang) Wu wrote:
On VCN v4.0.5 there is a race condition where the WPTR is not
updated after starting from idle when doorbell is used. The read-back
of regVCN_RB1_DB_CTRL register after written is to ensure the
doorbell_index is updated before it can work proper
On VCN v4.0.5 there is a race condition where the WPTR is not
updated after starting from idle when doorbell is used. The read-back
of regVCN_RB1_DB_CTRL register after written is to ensure the
doorbell_index is updated before it can work properly.
Link: https://gitlab.freedesktop.org/mesa/mesa/-/
Similar to the previous changes made for VCN v4.0.5, the addition of
register read-back support in VCN v4.0.0 and v5.0.0 is intended to
prevent potential race conditions, even though such issues have not
been observed yet. This change ensures consistency across different
VCN variants and helps avoi
[AMD Official Use Only - AMD Internal Distribution Only]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Lazar, Lijo
Sent: Friday, May 9, 2025 19:37
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad ; Lin, Amber
Su
On 04/29, Alex Hung wrote:
> This is an RFC set for a color pipeline API, along with implementations
> in VKMS and amdgpu. It is tested with a set of IGT tests that can be
> found at [1]. The IGT tests run a pixel-by-pixel comparison with an
> allowable delta variation as the goal for these transfo
On 05/12, Alex Hung wrote:
>
>
> On 5/12/25 18:52, Melissa Wen wrote:
> > On 04/29, Alex Hung wrote:
> > > This adds support for a 3D LUT.
> > >
> > > The color pipeline now consists of the following colorops:
> > > 1. 1D curve colorop
> > > 2. Multiplier
> > > 3. 3x4 CTM
> > > 4. 1D curve color
On 05/13, Pekka Paalanen wrote:
> On Mon, 12 May 2025 15:50:17 -0300
> Melissa Wen wrote:
>
> > On 04/29, Alex Hung wrote:
> > > Expose one 1D curve colorop with support for
> > > DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
> > > the sRGB transform when the colorop is not in bypass.
On 5/9/2025 5:07 PM, Lijo Lazar wrote:
> Compatible NPS modes for a partition mode are exposed through xcp_config
> interface. To determine if a compute partition mode is valid, check if
> the current NPS mode is part of compatible NPS modes.
>
> Signed-off-by: Lijo Lazar
> ---
> drivers/gpu/d
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Asad Kamal
Thanks & Regards
Asad
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, May 13, 2025 7:20 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad
Subject: [PATCH] drm
[AMD Official Use Only - AMD Internal Distribution Only]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Kamal, Asad
Sent: Tuesday, May 13, 2025 19:22
To: amd-gfx@lists.freedesktop.org; Lazar, Lijo
Cc: Zhang, Hawking ; Ma, Le ; Zhang,
Morris ; Kamal, As
On Fri, May 9, 2025 at 8:34 AM Tvrtko Ursulin wrote:
>
> 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 thi
On Tue, May 13, 2025 at 9:58 AM Lijo Lazar wrote:
>
> Move them to SMUv13.0.6 header file as they are used only in SMU
> v13.0.6.
>
> Signed-off-by: Lijo Lazar
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 9 -
> drivers/gpu/drm/amd/pm/swsmu/
Move them to SMUv13.0.6 header file as they are used only in SMU
v13.0.6.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 9 -
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.h | 8
2 files changed, 8 insertions(+), 9 deletions(-)
diff --
These log messages are overwhelming during the boot process.
Acked-by: Arvind Yadav
~arvind
On 5/13/2025 7:05 PM, Harry Wentland wrote:
On 2025-05-12 23:20, Wayne Lin wrote:
It's expected that we'll encounter temporary exceptions
during aux transactions. Adjust logging from drm_info to
drm_d
On 2025-05-12 23:20, Wayne Lin wrote:
> It's expected that we'll encounter temporary exceptions
> during aux transactions. Adjust logging from drm_info to
> drm_dbg_dp to prevent flooding with unnecessary log messages.
>
> Fixes: 6285f12bc54c ("drm/amd/display: Fix wrong handling for AUX_DEFER
On Mon, May 12, 2025 at 11:28 PM Wayne Lin wrote:
>
> It's expected that we'll encounter temporary exceptions
> during aux transactions. Adjust logging from drm_info to
> drm_dbg_dp to prevent flooding with unnecessary log messages.
>
> Fixes: 6285f12bc54c ("drm/amd/display: Fix wrong handling for
On Mon, 12 May 2025 15:50:17 -0300
Melissa Wen wrote:
> On 04/29, Alex Hung wrote:
> > Expose one 1D curve colorop with support for
> > DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
> > the sRGB transform when the colorop is not in bypass.
> >
> > With this change the following IGT te
On 5/13/2025 2:43 PM, Shiwu Zhang wrote:
> Expose the debugfs file node for user space to dump the IFWI image
> on spirom.
>
> For one transaction between PSP and host, it will read out the
> images on both active and inactive partitions so a buffer with two
> times the size of maximum IFWI ima
From: Taimur Hassan
Refactoring some DMUB related structs and enum.
Acked-by: Wayne Lin
Signed-off-by: Taimur Hassan
Signed-off-by: Tom Chung
---
.../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 34 +--
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
From: Samson Tam
[Why & How]
Add support for 2nd sharpening range for cases where we want
override existing DCN sharpening range.
Reviewed-by: Alvin Lee
Signed-off-by: Samson Tam
Signed-off-by: Tom Chung
---
drivers/gpu/drm/amd/display/dc/sspl/dc_spl_types.h | 4
1 file changed, 4 inser
From: Taimur Hassan
This version brings along following update:
-Support external tunneling feature
-Modify DCN401 DMUB reset & halt sequence
-Fix the typo in dcn401 Hubp block
-Skip backend validation for virtual monitors
Acked-by: Wayne Lin
Signed-off-by: Taimur Hassan
Signed-off-by: Tom Chu
From: Ovidiu Bunea
[why & how]
GPINTs can timeout without returning any data. Since this path is
only for testing purposes, it should retry several times to ensure
data is collected.
Reviewed-by: Nicholas Kazlauskas
Signed-off-by: Ovidiu Bunea
Signed-off-by: Tom Chung
---
drivers/gpu/drm/amd
From: Dillon Varone
[WHY&HOW]
If DMCUB is already disabled or reset, no need to send the halt command
again.
Reviewed-by: Nicholas Kazlauskas
Signed-off-by: Dillon Varone
Signed-off-by: Tom Chung
---
.../gpu/drm/amd/display/dmub/src/dmub_dcn401.c | 16 ++--
1 file changed, 6 in
From: Nevenko Stupar
[Why & How]
Fix the typo for hubp_clear_tiling, currently calls hubp2_clear_tiling
for dcn401 instead of intended hubp401_clear_tiling.
Reviewed-by: Aurabindo Pillai
Signed-off-by: Nevenko Stupar
Signed-off-by: Tom Chung
---
drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn
From: Chiawen Huang
[Why&How]
Virtual monitors are now being validated during set_mode.
Virtual monitors should not undergo backend validation,
as the backend is intended only for physical monitors.
Virtual sinks have no real backend part information and
should be excluded from this validation.
From: Karthi Kandasamy
[Why]
mcache allocation programming is not part of DML's core responsibilities.
Keeping this logic in DML leads to poor separation of concerns and complicates
maintenance.
[How]
Refactored code to move mcache parameter preparation and mcache ID assignment
into the resourc
From: Cruise Hung
[Why & How]
The original code only supports the tunneling for embedded one.
To support external tunneling feature, it needs to check
Tunneling_Support bit register.
Reviewed-by: Wenjing Liu
Reviewed-by: Jun Lei
Signed-off-by: Cruise Hung
Signed-off-by: Tom Chung
---
.../gp
From: Yihan Zhu
[WHY & HOW]
Uninitialized local variables will cause format checker complain
about them.
Reviewed-by: Charlene Liu
Signed-off-by: Yihan Zhu
Signed-off-by: Tom Chung
---
.../amd/display/dc/hwss/dcn401/dcn401_hwseq.c| 16
1 file changed, 8 insertions(+), 8
From: Tomasz Siemek
[WHY]
dc_plane_get_status may be used for reading other plane properties
in the future.
[HOW]
Provide API for choosing plane properties to read.
Reviewed-by: Charlene Liu
Reviewed-by: Aric Cyr
Reviewed-by: Swapnil Patel
Signed-off-by: Tomasz Siemek
Signed-off-by: Tom Chu
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
-Support external tunneling feature
-Modify DCN401 DMUB reset & halt sequence
-Fix the typo in dcn401 Hubp block
-Skip backend validation for virtual monitors
Cc: Daniel Wheeler
Chiawen Huang (1):
drm/amd/disp
Update pmfw headers for smu_v_13_0_6 to include pldm version
as part of statics metrics table
Signed-off-by: Asad Kamal
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_6_pmfw.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
Fetch pldm version from static metrics table for SMU v13.0.6 SOCs
Signed-off-by: Asad Kamal
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 7 +++
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/
Add pldm version reporting through sysfs node
Signed-off-by: Asad Kamal
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdg
Expose the debugfs file node for user space to dump the IFWI image
on spirom.
For one transaction between PSP and host, it will read out the
images on both active and inactive partitions so a buffer with two
times the size of maximum IFWI image (currently 16MByte) is needed.
v2: move the vbios gf
[AMD Official Use Only - AMD Internal Distribution Only]
[public]
> -Original Message-
> From: Zhang, Hawking
> Sent: Monday, May 12, 2025 10:25 PM
> To: Zhang, Morris ; Gao, Likun ;
> amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH] drm/amdgpu: add debugfs for spirom IFWI dump
>
> [
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
> Currently the job free work item will lock sched->job_list_lock first
> time
> to see if there are any jobs, free a single job, and then lock again
> to
> decide whether to re-queue itself if there are more finished jobs.
>
> Since drm_sch
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of
> Jesse.Zhang
> Sent: Tuesday, May 13, 2025 10:21 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Zhang, Jesse(Jie)
> Subject: [PATCH] drm/amdgpu: Fix circular locking in userq creation
>
>
Hi Krzysztof,
Thanks for the feedback.
Em 12/05/2025 03:08, Krzysztof Karas escreveu:
Hi André,
[...]
@@ -582,6 +584,14 @@ int drm_dev_wedged_event(struct drm_device *dev, unsigned
long method)
drm_info(dev, "device wedged, %s\n", method == DRM_WEDGE_RECOVERY_NONE ?
This patchset implements a request made by Xaver Hugl about wedge events:
"I'd really like to have the PID of the client that triggered the GPU
reset, so that we can kill it if multiple resets are triggered in a
row (or switch to software rendering if it's KWin itself) and show a
user-friendly not
* Alex Deucher (alexdeuc...@gmail.com) wrote:
> On Sun, May 11, 2025 at 8:13 AM Dr. David Alan Gilbert
> wrote:
> >
> > * Christophe JAILLET (christophe.jail...@wanadoo.fr) wrote:
> > > Le 18/04/2025 à 02:21, li...@treblig.org a écrit :
> > > > From: "Dr. David Alan Gilbert"
> > > >
> > > > radeo
On Fri, May 9 2025 at 03:01:13 PM +, Steven J Abner
wrote:
On Fri, May 9 2025 at 02:05:16 PM +, Alex Deucher
wrote:
bisect between 6.2.16 and 6.2.17 to identify the commit which broke
Are you asking for a 'diff' output of drm and amdgpu directories
between 6.2.16 (last of the 6.2 se
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
> Now that the run queue to scheduler relationship is always 1:1 we can
> embed it (the run queue) directly in the scheduler struct and save on
> some allocation error handling code and such.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christia
On Mon, 2025-05-12 at 14:23 +0200, Marcus Rückert wrote:
> > I opened a video in clapper to take the browser out of the equation
> > and
> > started working in a terminal. -> kernel oops. will look into setting
> > up kdump.
> >
> > Mesa-25.1+git1019.7c4f501e9-39.1.x86_64
> > kernel-default-6.1
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
> Reduce to one spin_unlock for hopefully a little bit clearer flow in
> the
> function. It may appear that there is a behavioural change with the
> drm_sched_start_timeout_unlocked() now not being called if there were
> initially no jobs on
Add a section about "App information" for the wedge API.
Signed-off-by: André Almeida
---
v3:
- Change "app that caused ..." to "app involved ..."
- Clarify that devcoredump have more information about what happened
- Update that PID and APP will be empty if there's no app info
---
Documentat
From: Wayne Lin
[ Upstream commit fcf6a49d79923a234844b8efe830a61f3f0584e4 ]
[Why]
When unplug one of monitors connected after mst hub, encounter null pointer
dereference.
It's due to dc_sink get released immediately in early_unregister() or
detect_ctx(). When
commit new state which directly
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/amdgpu/amdgpu_device.c | 19 +--
drivers/gpu/drm/amd/amdgpu/amdg
On Mon, May 12, 2025 at 01:22:01PM +, Lin, Wayne wrote:
> It's due to a newly merged patch which adds more logs indicating exceptions
> while doing AUX transactions. These exceptions might be temporary state with
> the DPRx.
> Will give another patch to adjust the log. Sorry for any inconvenien
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 the compositor to let the user know what app caused the problem.
This is an optiona
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
> To implement fair scheduling we will need as accurate as possible
> view
> into per entity GPU time utilisation. Because sched fence execution
> time
> are only adjusted for accuracy in the free worker we need to process
> completed jobs as
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
> There is no need to keep entities with no jobs in the tree so lets
> remove
> it once the last job is consumed. This keeps the tree smaller which
> is
> nicer and more efficient as entities are removed and re-added on
> every
> popped job.
On Sun, May 11, 2025 at 07:47:44PM -0300, André Almeida wrote:
> Add a section about "App information" for the wedge API.
>
> Signed-off-by: André Almeida
> ---
> Documentation/gpu/drm-uapi.rst | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.
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/gpu/drm/i915/gt/intel_gt_requests.c | 2 ++
drivers/gpu/drm/i915/i915_request.c | 5 +++--
drivers/gpu/drm/i915/i915_sw_fenc
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-
Access the dma-fence internals via the previously added helpers.
Drop the macro while at it, since the length is now more manageable.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/
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().
Signed-off-by: Tvrtko Urs
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
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
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/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
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
1 - 100 of 102 matches
Mail list logo
