linux-stable.git/drivers/gpu/drm/amd/display/amdgpu_dm, branch linux-6.13.y

drm/amd: Keep display off while going into S4

2025-04-10T12:41:55+00:00

[ Upstream commit 4afacc9948e1f8fdbca401d259ae65ad93d298c0 ]

When userspace invokes S4 the flow is:

1) amdgpu_pmops_prepare()
2) amdgpu_pmops_freeze()
3) Create hibernation image
4) amdgpu_pmops_thaw()
5) Write out image to disk
6) Turn off system

Then on resume amdgpu_pmops_restore() is called.

This flow has a problem that because amdgpu_pmops_thaw() is called
it will call amdgpu_device_resume() which will resume all of the GPU.

This includes turning the display hardware back on and discovering
connectors again.

This is an unexpected experience for the display to turn back on.
Adjust the flow so that during the S4 sequence display hardware is
not turned back on.

Reported-by: Xaver Hugl 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2038
Cc: Muhammad Usama Anjum 
Tested-by: Muhammad Usama Anjum 
Acked-by: Alex Deucher 
Acked-by: Harry Wentland 
Link: https://lore.kernel.org/r/20250306185124.44780-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello 
Signed-off-by: Alex Deucher 
(cherry picked from commit 68bfdc8dc0a1a7fdd9ab61e69907ae71a6fd3d91)
Signed-off-by: Sasha Levin

drm/amd/display: Fix message for support_edp0_on_dp1

2025-03-28T21:04:57+00:00

commit 35f0f9f421390f66cb062f4d79f4924af5f55b04 upstream.

[WHY]
The info message was wrong when support_edp0_on_dp1 is enabled

[HOW]
Use correct info message for support_edp0_on_dp1

Fixes: f6d17270d18a ("drm/amd/display: add a quirk to enable eDP0 on DP1")
Reviewed-by: Aurabindo Pillai 
Signed-off-by: Yilin Chen 
Signed-off-by: Alex Hung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 79538e6365c99d7b1c3e560d1ea8d11ef8313465)
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:56:55+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: Restore correct backlight brightness after a GPU reset

2025-03-22T19:56:55+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: fix default brightness

2025-03-22T19:56:54+00:00

commit b5a981e1b34e44f94a5967f730fff4166f2101e8 upstream.

[Why]
To avoid flickering during boot default brightness level set by BIOS
should be maintained for as much of the boot as feasible.
commit 2fe87f54abdc ("drm/amd/display: Set default brightness according
to ACPI") attempted to set the right levels for AC vs DC, but brightness
still got reset to maximum level in initialization code for
setup_backlight_device().

[How]
Remove the hardcoded initialization in setup_backlight_device() and
instead program brightness value to match BIOS (AC or DC).  This avoids a
brightness flicker from kernel changing the value.  Userspace may however
still change it during boot.

Fixes: 2fe87f54abdc ("drm/amd/display: Set default brightness according to ACPI")
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 0747acf3311229e22009bec4a9e7fc30c879e842)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

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

2025-03-22T19:56:54+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

drm/amdgpu/display: Allow DCC for video formats on GFX12

2025-03-22T19:56:54+00:00

commit df1e82e7acd3c50b65ca0e2e09089b78382d14ab upstream.

We advertise DCC as supported for NV12/P010 formats on GFX12,
but it would fail on this check on atomic commit.

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

drm/amd/display: Fix HPD after gpu reset

2025-03-07T17:27:07+00:00

commit 4de141b8b1b7991b607f77e5f4580e1c67c24717 upstream.

[Why]
DC is not using amdgpu_irq_get/put to manage the HPD interrupt refcounts.
So when amdgpu_irq_gpu_reset_resume_helper() reprograms all of the IRQs,
HPD gets disabled.

[How]
Use amdgpu_irq_get/put() for HPD init/fini in DM in order to sync refcounts

Cc: Mario Limonciello 
Cc: Alex Deucher 
Reviewed-by: Mario Limonciello 
Reviewed-by: Aurabindo Pillai 
Signed-off-by: Roman Li 
Signed-off-by: Zaeem Mohamed 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit f3dde2ff7fcaacd77884502e8f572f2328e9c745)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: add a quirk to enable eDP0 on DP1

2025-03-07T17:27:07+00:00

commit b5f7242e49b927cfe488b369fa552f2eff579ef1 upstream.

[why]
some board designs have eDP0 connected to DP1, need a way to enable
support_edp0_on_dp1 flag, otherwise edp related features cannot work

[how]
do a dmi check during dm initialization to identify systems that
require support_edp0_on_dp1. Optimize quirk table with callback
functions to set quirk entries, retrieve_dmi_info can set quirks
according to quirk entries

Cc: Mario Limonciello 
Reviewed-by: Mario Limonciello 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Yilin Chen 
Signed-off-by: Zaeem Mohamed 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit f6d17270d18a6a6753fff046330483d43f8405e4)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Disable PSR-SU on eDP panels

2025-03-07T17:27:07+00:00

commit e8863f8b0316d8ee1e7e5291e8f2f72c91ac967d upstream.

[Why]
PSR-SU may cause some glitching randomly on several panels.

[How]
Temporarily disable the PSR-SU and fallback to PSR1 for
all eDP panels.

Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3388
Cc: Mario Limonciello 
Cc: Alex Deucher 
Reviewed-by: Sun peng Li 
Signed-off-by: Tom Chung 
Signed-off-by: Roman Li 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 6deeefb820d0efb0b36753622fb982d03b37b3ad)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman