kernel/linux.git/drivers/gpu/drm/amd/display/amdgpu_dm, branch v6.1.5

Revert "drm/amd/display: Enable Freesync Video Mode by default"

2023-01-12T11:02:46+00:00

commit 6fe6ece398f7431784847e922a2c8c385dc58a35 upstream. This reverts commit de05abe6b9d0fe08f65d744f7f75a4cba4df27ad. The bug referenced below was bisected to this commit. There has been no activity toward fixing it in 3 months, so let's revert for now. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2162 Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Report to ACPI video if no panels were found

2023-01-12T11:02:40+00:00

[ Upstream commit c573e240609ff781a0246c0c8c8351abd0475287 ] On desktop APUs amdgpu doesn't create a native backlight device as no eDP panels are found. However if the BIOS has reported backlight control methods in the ACPI tables then an acpi_video0 backlight device will be made 8 seconds after boot. This has manifested in a power slider on a number of desktop APUs ranging from Ryzen 5000 through Ryzen 7000 on various motherboard manufacturers. To avoid this, report to the acpi video detection that the system does not have any panel connected in the native driver. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1783786 Reported-by: Hans de Goede Signed-off-by: Mario Limonciello Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

drm/amd/display: Add DCN314 display SG Support

2023-01-07T10:12:03+00:00

commit fe6872adb05e85bde38f2cdec01a0f4cfb826998 upstream. Add display SG support for DCN 3.1.4. Signed-off-by: Yifan Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

Revert "drm/amd/display: Limit max DSC target bpp for specific monitors"

2022-12-31T12:32:59+00:00

[ Upstream commit 6803dfd3a69ccb318772463a86e40929fd4fbac7 ] This reverts commit 55eea8ef98641f6e1e1c202bd3a49a57c1dd4059. This quirk is now handled in the DRM core, so we can drop all of the internal code that was added to handle it. Reviewed-by: Harry Wentland Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: No display after resume from WB/CB

2022-11-23T14:01:53+00:00

[why] First MST sideband message returns AUX_RET_ERROR_HPD_DISCON on certain intel platform. Aux transaction considered failure if HPD unexpected pulled low. The actual aux transaction success in such case, hence do not return error. [how] Not returning error when AUX_RET_ERROR_HPD_DISCON detected on the first sideband message. v2: squash in fix (Alex) Reviewed-by: Jerry Zuo Acked-by: Brian Chang Signed-off-by: Tsung-hua Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/amdgpu/dm/mst: Fix uninitialized var in pre_compute_mst_dsc_configs_for_state()

2022-11-21T21:39:26+00:00

Coverity noticed this one, so let's fix it. Fixes: ba891436c2d2b2 ("drm/amdgpu/mst: Stop ignoring error codes and deadlocking") Signed-off-by: Lyude Paul Signed-off-by: Alex Deucher Reviewed-by: Harry Wentland Cc: stable@vger.kernel.org # v5.6+

drm/amdgpu/dm/dp_mst: Don't grab mst_mgr->lock when computing DSC state

2022-11-21T21:38:50+00:00

Now that we've fixed the issue with using the incorrect topology manager, we're actually grabbing the topology manager's lock - and consequently deadlocking. Luckily for us though, there's actually nothing in AMD's DSC state computation code that really should need this lock. The one exception is the mutex_lock() in dm_dp_mst_is_port_support_mode(), however we grab no locks beneath &mgr->lock there so that should be fine to leave be. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Lyude Paul Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: # v5.6+ Reviewed-by: Wayne Lin Signed-off-by: Alex Deucher

drm/amdgpu/dm/mst: Use the correct topology mgr pointer in amdgpu_dm_connector

2022-11-21T21:38:42+00:00

This bug hurt me. Basically, it appears that we've been grabbing the entirely wrong mutex in the MST DSC computation code for amdgpu! While we've been grabbing: amdgpu_dm_connector->mst_mgr That's zero-initialized memory, because the only connectors we'll ever actually be doing DSC computations for are MST ports. Which have mst_mgr zero-initialized, and instead have the correct topology mgr pointer located at: amdgpu_dm_connector->mst_port->mgr; I'm a bit impressed that until now, this code has managed not to crash anyone's systems! It does seem to cause a warning in LOCKDEP though: [ 66.637670] DEBUG_LOCKS_WARN_ON(lock->magic != lock) This was causing the problems that appeared to have been introduced by: commit 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state") This wasn't actually where they came from though. Presumably, before the only thing we were doing with the topology mgr pointer was attempting to grab mst_mgr->lock. Since the above commit however, we grab much more information from mst_mgr including the atomic MST state and respective modesetting locks. This patch also implies that up until now, it's quite likely we could be susceptible to race conditions when going through the MST topology state for DSC computations since we technically will not have grabbed any lock when going through it. So, let's fix this by adjusting all the respective code paths to look at the right pointer and skip things that aren't actual MST connectors from a topology. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Lyude Paul Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: # v5.6+ Reviewed-by: Wayne Lin Signed-off-by: Alex Deucher

drm/amdgpu/mst: Stop ignoring error codes and deadlocking

2022-11-21T21:38:23+00:00

It appears that amdgpu makes the mistake of completely ignoring the return values from the DP MST helpers, and instead just returns a simple true/false. In this case, it seems to have come back to bite us because as a result of simply returning false from compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a deadlock happened from these helpers. This could definitely result in some kernel splats. V2: * Address Wayne's comments (fix another bunch of spots where we weren't passing down return codes) Signed-off-by: Lyude Paul Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: Harry Wentland Cc: # v5.6+ Reviewed-by: Wayne Lin Signed-off-by: Alex Deucher

drm/amd/display: don't enable DRM CRTC degamma property for DCE

2022-11-15T18:23:48+00:00

DM maps DRM CRTC degamma to DPP (pre-blending) degamma block, but DCE doesn't support programmable degamma curve anywhere. Currently, a custom degamma is accepted by DM but just ignored by DCE driver and degamma correction isn't actually applied. There is no way to map custom degamma in DCE, therefore, DRM CRTC degamma property shouldn't be enabled for DCE drivers. Reviewed-by: Rodrigo Siqueira Signed-off-by: Melissa Wen Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org