linux-stable.git/drivers/gpu/drm/amd, branch v6.6.86

drm/amd/display: Don't write DP_MSTM_CTRL after LT

2025-04-07T08:06:36+00:00

commit bc068194f548ef1f230d96c4398046bf59165992 upstream.

[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 register.

[How]
We already resume the mst branch device dpcd settings during
resume_mst_branch_status(). Leverage drm_dp_mst_topology_queue_probe() to
only probe the topology, not calling drm_dp_mst_topology_mgr_resume() which
will set DP_MSTM_CTRL as well.

Reviewed-by: Jerry Zuo 
Signed-off-by: Wayne Lin 
Signed-off-by: Zaeem Mohamed 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
[cascardo: adjust context in local declarations]
Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Check denominator crb_pipes before used

2025-04-07T08:06:36+00:00

commit ea79068d4073bf303f8203f2625af7d9185a1bc6 upstream.

[WHAT & HOW]
A denominator cannot be 0, and is checked before used.

This fixes 2 DIVIDE_BY_ZERO issues reported by Coverity.

Reviewed-by: Harry Wentland 
Signed-off-by: Jerry Zuo 
Signed-off-by: Alex Hung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Cliff Liu 
Signed-off-by: He Zhe 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Use HW lock mgr for PSR1 when only one eDP

2025-03-28T20:59:56+00:00

commit acbf16a6ae775b4db86f537448cc466288aa307e upstream.

[WHY]
DMUB locking is important to make sure that registers aren't accessed
while in PSR.  Previously it was enabled but caused a deadlock in
situations with multiple eDP panels.

[HOW]
Detect if multiple eDP panels are in use to decide whether to use
lock. Refactor the function so that the first check is for PSR-SU
and then replay is in use to prevent having to look up number
of eDP panels for those configurations.

Fixes: f245b400a223 ("Revert "drm/amd/display: Use HW lock mgr for PSR1"")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3965
Reviewed-by: ChiaHsuan Chung 
Signed-off-by: Mario Limonciello 
Signed-off-by: Alex Hung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit ed569e1279a3045d6b974226c814e071fa0193a6)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: should support dmub hw lock on Replay

2025-03-28T20:59:55+00:00

commit bfeefe6ea5f18cabb8fda55364079573804623f9 upstream.

[Why]
Without acquiring DMCUB hw lock, a race condition is caused with
Panel Replay feature, which will trigger a hang. Indicate that a
lock is necessary to prevent this when replay feature is enabled.

[How]
To allow dmub hw lock on Replay.

Reviewed-by: Robin Chen 
Acked-by: Aurabindo Pillai 
Signed-off-by: Martin Tsai 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix JPEG video caps max size for navi1x and raven

2025-03-28T20:59:55+00:00

commit ec33964d9d88488fa954a03d476a8b811efc6e85 upstream.

8192x8192 is the maximum supported resolution.

Signed-off-by: David Rosca 
Acked-by: Alex Deucher 
Reviewed-by: Ruijing Dong 
Signed-off-by: Alex Deucher 
(cherry picked from commit 6e0d2fde3ae8fdb5b47e10389f23ed2cb4daec5d)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix MPEG2, MPEG4 and VC1 video caps max size

2025-03-28T20:59:55+00:00

commit f0105e173103c9d30a2bb959f7399437d536c848 upstream.

1920x1088 is the maximum supported resolution.

Signed-off-by: David Rosca 
Acked-by: Alex Deucher 
Reviewed-by: Ruijing Dong 
Signed-off-by: Alex Deucher 
(cherry picked from commit 1a0807feb97082bff2b1342dbbe55a2a9a8bdb88)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix slab-use-after-free on hdcp_work

2025-03-22T19:50:47+00:00

commit e65e7bea220c3ce8c4c793b4ba35557f4994ab2b upstream.

[Why]
A slab-use-after-free is reported when HDCP is destroyed but the
property_validate_dwork queue is still running.

[How]
Cancel the delayed work when destroying workqueue.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4006
Fixes: da3fd7ac0bcf ("drm/amd/display: Update CP property based on HW query")
Cc: Alex Deucher 
Reviewed-by: Alex Hung 
Signed-off-by: Mario Limonciello 
Signed-off-by: Tom Chung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Assign normalized_pix_clk when color depth = 14

2025-03-22T19:50:47+00:00

commit 79e31396fdd7037c503e6add15af7cb00633ea92 upstream.

[WHY & HOW]
A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397
calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because the
display_color_depth == COLOR_DEPTH_141414 is not handled. This is
observed in Radeon RX 6600 XT.

It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.

Also fixes the indentation in get_norm_pix_clk.

Reviewed-by: Harry Wentland 
Signed-off-by: Alex Hung 
Signed-off-by: Tom Chung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Restore correct backlight brightness after a GPU reset

2025-03-22T19:50:47+00:00

commit 5760388d9681ac743038b846b9082b9023969551 upstream.

[Why]
GPU reset will attempt to restore cached state, but brightness doesn't
get restored. It will come back at 100% brightness, but userspace thinks
it's the previous value.

[How]
When running resume sequence if GPU is in reset restore brightness
to previous value.

Acked-by: Wayne Lin 
Signed-off-by: Mario Limonciello 
Signed-off-by: Tom Chung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 5e19e2b57b6bb640d68dfc7991e1e182922cf867)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Disable unneeded hpd interrupts during dm_init

2025-03-22T19:50:47+00:00

commit 40b8c14936bd2726354c856251f6baed9869e760 upstream.

[Why]

It seems HPD interrupts are enabled by default for all connectors, even
if the hpd source isn't valid. An eDP for example, does not have a valid
hpd source (but does have a valid hpdrx source; see construct_phy()).
Thus, eDPs should have their hpd interrupt disabled.

In the past, this wasn't really an issue. Although the driver gets
interrupted, then acks by writing to hw registers, there weren't any
subscribed handlers that did anything meaningful (see
register_hpd_handlers()).

But things changed with the introduction of IPS. s2idle requires that
the driver allows IPS for DMUB fw to put hw to sleep. Since register
access requires hw to be awake, the driver will block IPS entry to do
so. And no IPS means no hw sleep during s2idle.

This was the observation on DCN35 systems with an eDP. During suspend,
the eDP toggled its hpd pin as part of the panel power down sequence.
The driver was then interrupted, and acked by writing to registers,
blocking IPS entry.

[How]

Since DC marks eDP connections as having invalid hpd sources (see
construct_phy()), DM should disable them at the hw level. Do so in
amdgpu_dm_hpd_init() by disabling all hpd ints first, then selectively
enabling ones for connectors that have valid hpd sources.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Reviewed-by: Harry Wentland 
Signed-off-by: Leo Li 
Signed-off-by: Tom Chung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 7b1ba19eb15f88e70782642ce2d934211269337b)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman