From: Andrey Vatoropin
Static analysis shows that pointer "svms" cannot be NULL because it points
to the object "struct svm_range_list". Remove the extra NULL check. It is
meaningless and harms the readability of the code.
In the function svm_range_get_info() there is no possibility of failure.
Hi Alex,
On Wed, 26 Mar 2025 at 23:50, Alex Hung wrote:
> +static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
> *colorop,
> + struct drm_plane *plane, enum drm_colorop_type
> type)
> +{
> + struct drm_mode_config *config = &dev->mode_config;
>
On 3/31/2025 6:31 PM, Christian König wrote:
This reverts commit c2cc3648ba517a6c270500b5447d5a1efdad5936.
Turned out that this has some negative consequences for some workloads.
Instead check if the cleaner shader should run directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd
On Mon, 31 Mar 2025, Thadeu Lima de Souza Cascardo wrote:
> From: Wayne Lin
>
> [ Upstream commit bc068194f548ef1f230d96c4398046bf59165992 ]
>
> [Why]
> Observe after suspend/resme, we can't light up mst monitors under specific
> mst hub.
This is already at stable backport stage, but it would re
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Asad Kamal
Thanks & Regards
Asad
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, April 1, 2025 4:55 PM
To: amd-gfx@lists.freedesktop.org; Lazar, Lijo
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad
Subje
Am 01.04.25 um 12:32 schrieb SRINIVASAN SHANMUGAM:
> On 3/31/2025 6:31 PM, Christian König wrote:
>> Otherwise triggering sysfs multiple times without other submissions in
>> between only runs the shader once.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
On 2025-03-31 19:42, Alex Hung wrote:
> On 3/31/25 11:04, Shengyu Qu wrote:
>> Or we can add some kind of "linked with" info to plane's COLOR_PIPELINE
>> property, to let userspace know that cursor plane and background plane share
>> the same colorop config. So that userspace could do extra conve
From: Tony Yi
CPER read will loop infinitely if an error is encountered and
the more bit is set. Add error checks to break upon failure.
v2: added function pointer checks
Suggested-by: Tony Yi
Signed-off-by: Victor Skvortsov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 16
Hi,
For what I read on the reporting issue, I think the issue I am facing qualify
for regression, but as I am a noob yet I'm not sure.
I reported it to gitlab link as described in the maintainers list. Below is the
issue report link.
https://gitlab.freedesktop.org/drm/amd/-/issues/4098
Sorry for
On 2025-04-01 11:45, Melissa Wen wrote:
> On 03/31, Xaver Hugl wrote:
>>> Cursor plane has no color pipeline and thus it has no colorop either. It
>>> inherits color processing from its parent plane.
>>
>> Just to be sure: That means amdgpu will reject atomic commits that try
>> to set a color p
On 2025-04-01 11:45, Shengyu Qu wrote:
>
>
> 在 2025/4/1 22:11, Michel Dänzer 写道:
>> On 2025-04-01 14:32, Shengyu Qu wrote:
>>> 在 2025/4/1 17:56, Michel Dänzer 写道:
On 2025-03-31 19:42, Alex Hung wrote:
> On 3/31/25 11:04, Shengyu Qu wrote:
>> Or we can add some kind of "linked with
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Harish Kasiviswanathan
-Original Message-
From: amd-gfx On Behalf Of Jay Cornwall
Sent: Monday, March 31, 2025 11:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Cornwall, Jay ; Russell, Kent
Subject: [PATCH v3] drm/am
On Tuesday, April 1st, 2025 at 17:14, Daniel Stone wrote:
>
>
> Hi Alex,
>
> On Wed, 26 Mar 2025 at 23:50, Alex Hung alex.h...@amd.com wrote:
>
> > +static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
> > *colorop,
> > + struct drm_plane *plane, enum drm_colorop_type
On 2025-03-27 05:53, Huacai Chen wrote:
Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context
start") removes the FP context protection of dml2_create(), and it said
"All the DC_FP_START/END should be used before call anything from DML2".
However, dml21_copy() are not protected
From: "jesse.zh...@amd.com"
This patch refactors the SDMA v5.0 reset logic by splitting the
`sdma_v5_0_reset_queue` function into two separate functions:
`sdma_v5_0_stop_queue` and `sdma_v5_0_restore_queue`.
This change aligns with the new SDMA reset mechanism, where the reset process
is divid
From: "jesse.zh...@amd.com"
This patch removes the deprecated SDMA reset callback mechanism, which was
previously used to register pre-reset and post-reset callbacks for SDMA engine
resets.
The SDMA reset callback mechanism allowed KFD and AMDGPU to register pre-reset
and post-reset functions
On 31/03/2025 21:16, Tvrtko Ursulin wrote:
Rq->lock only protects the tree walk so lets move the rest out.
I retract this one, reinit_completion has to be in the locked section
too. Next posting will be rebased accordingly but I will hold off
sending it out until more comments are received.
Use the right register offsets for getting link status.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdg
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Skvortsov, Victor
Sent: Wednesday, April 2, 2025 04:59
To: amd-gfx@lists.freedesktop.org
Cc: Luo, Zhigang ; Zhang, Hawking ;
Zhou1, Tao ; Zhao, Victor ; Yi, Ton
From: "jesse.zh...@amd.com"
Since KFD no longer registers its own callbacks for SDMA resets, and only KGD
uses the reset mechanism,
we can simplify the SDMA reset flow by directly calling the ring's `stop_queue`
and `start_queue` functions.
This patch removes the dynamic callback mechanism and
From: "jesse.zh...@amd.com"
This patch refactors the SDMA v5.0 queue reset and stop logic to improve
code readability, maintainability, and performance. The key changes include:
1. **Generalized `sdma_v5_0_gfx_stop` Function**:
- Added an `inst_mask` parameter to allow stopping specific SDMA
From: Mario Limonciello
AMD RX580 when added AMD Phenom 2 has problems with overheating. This is
due to changes with PCIe dynamic switching introduced by commit
466a7d115326e ("drm/amd: Use the first non-dGPU PCI device for BW limits")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4098
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Skvortsov, Victor
Sent: Wednesday, April 2, 2025 04:44
To: amd-gfx@lists.freedesktop.org
Cc: Luo, Zhigang ; Zhang, Hawking ;
Zhou1, Tao ; Zhao, Victor ; Yi, Ton
On 3/31/2025 6:31 PM, Christian König wrote:
Otherwise triggering sysfs multiple times without other submissions in
between only runs the shader once.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
di
ASPM doesn't need to be disabled if pcie dpm is disabled.
So ASPM can be independantly enabled.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu
在 2025/3/27 7:46, Alex Hung 写道:
From: Harry Wentland
With the introduction of the pre-blending color pipeline we
can no longer have color operations that don't have a clear
position in the color pipeline. We deprecate all existing
plane properties. For upstream drivers those are:
- COLOR_EN
Hi,
On 31-Mar-25 1:46 PM, Rafael J. Wysocki wrote:
> On Fri, Mar 28, 2025 at 10:09 PM Gergo Koteles wrote:
>>
>> The _DDC method should return a buffer, or an integer in case of an error.
>> But some Lenovo laptops incorrectly return EDID as buffer in ACPI package.
>>
>> Calling _DDC generates th
> Cursor plane has no color pipeline and thus it has no colorop either. It
> inherits color processing from its parent plane.
Just to be sure: That means amdgpu will reject atomic commits that try
to set a color pipeline on the primary plane while showing the cursor
plane on top of it? Just like w
Sorry for vague expression. I mean that I think we shouldn't register
DRM_PLANE_TYPE_CURSOR in the driver, as we don't have actual hardware
support.
在 2025/4/1 0:26, Alex Hung 写道:
On 3/31/25 10:12, Shengyu Qu wrote:
So currently we have to hope the compositor won't use
DRM_PLANE_TYPE_CURSOR
You are right. Sorry for the noise.
在 2025/4/1 0:41, Alex Hung 写道:
On 3/31/25 10:24, Shengyu Qu wrote:
在 2025/3/27 7:46, Alex Hung 写道:
From: Harry Wentland
Add documentation for color pipeline API.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
---
v8:
- Fix typo "definint"
在 2025/3/27 7:46, Alex Hung 写道:
From: Harry Wentland
Add documentation for color pipeline API.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
---
v8:
- Fix typo "definint" -> "defining"
v7:
- Add a commit messages
v5:
- Don't require BYPASS to succeed (Sebastian)
- use DA
From: Wayne Lin
[ Upstream commit bc068194f548ef1f230d96c4398046bf59165992 ]
[Why]
Observe after suspend/resme, we can't light up mst monitors under specific
mst hub. The reason is that driver still writes DPCD DP_MSTM_CTRL after LT.
It's forbidden even we write the same value for that dpcd regi
So currently we have to hope the compositor won't use
DRM_PLANE_TYPE_CURSOR planes at all Why do we still register
DRM_PLANE_TYPE_CURSOR in the driver?
在 2025/4/1 0:06, Alex Hung 写道:
On 3/31/25 09:43, Shengyu Qu wrote:
Hi,
Thanks for reply. So currently we have to apply color conversio
Hi,
Thanks for reply. So currently we have to apply color conversion on the
background plane of the cursor to do some color space conversion. What
would happen if cursor and background plane needs different conversion
config? Or we just give the cursor a dedicated plane?
Best regards,
Shengy
在 2025/4/1 1:42, Alex Hung 写道:
On 3/31/25 11:04, Shengyu Qu wrote:
Or we can add some kind of "linked with" info to plane's
COLOR_PIPELINE property, to let userspace know that cursor plane and
background plane share the same colorop config. So that userspace
could do extra conversion on cu
Hi,
For what I read on the reporting issue, I think the issue I am facing qualify
for regression, but as I am a noob yet I'm not sure.
I reported it to gitlab link as described in the maintainers list. Below is the
issue report link.
https://gitlab.freedesktop.org/drm/amd/-/issues/4098
Sorry for
From: Imre Deak
[ Upstream commit e9b36c5be2e7fdef2cc933c1dac50bd81881e9b8 ]
Factor out a function to queue a work for probing the topology, also
used by the next patch.
Cc: Lyude Paul
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Lyude Paul
Signed-off-by: Imre Deak
Link:
https://patchwo
Or we can add some kind of "linked with" info to plane's COLOR_PIPELINE
property, to let userspace know that cursor plane and background plane
share the same colorop config. So that userspace could do extra
conversion on cursor image data to avoid display wrong cursor color.
在 2025/4/1 0:50, S
From: Wayne Lin
[ Upstream commit bc068194f548ef1f230d96c4398046bf59165992 ]
[Why]
Observe after suspend/resme, we can't light up mst monitors under specific
mst hub. The reason is that driver still writes DPCD DP_MSTM_CTRL after LT.
It's forbidden even we write the same value for that dpcd regi
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 the pending list, and then some appeared after
unlock, however if t
On 03/31, Xaver Hugl wrote:
> > Cursor plane has no color pipeline and thus it has no colorop either. It
> > inherits color processing from its parent plane.
>
> Just to be sure: That means amdgpu will reject atomic commits that try
> to set a color pipeline on the primary plane while showing the
41 matches
Mail list logo
