linux-stable.git/drivers/gpu/drm/amd/display/amdgpu_dm, branch v6.1.2

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

drm/amd/display: Fix invalid DPIA AUX reply causing system hang

2022-11-15T18:10:38+00:00

[Why]
Some DPIA AUX replies have incorrect data length from original request.
This could lead to overwriting of destination buffer if reply length is
larger, which could cause invalid access to stack since many destination
buffers are declared as local variables.

[How]
Check for invalid length from DPIA AUX replies and trigger a retry if
reply length is not the same as original request. A DRM_WARN() dmesg log
is also produced.

Reviewed-by: Roman Li 
Acked-by: Tom Chung 
Signed-off-by: Stylon Wang 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org # 6.0.x

drm/amd/display: Fix access timeout to DPIA AUX at boot time

2022-11-15T18:05:43+00:00

[Why]
Since introduction of patch "Query DPIA HPD status.", link detection at
boot could be accessing DPIA AUX, which will not succeed until
DMUB outbox messaging is enabled and results in below dmesg logs:

[  160.840227] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* wait_for_completion_timeout timeout!

[How]
Enable DMUB outbox messaging before link detection at boot time.

Reviewed-by: Wayne Lin 
Acked-by: Tom Chung 
Signed-off-by: Stylon Wang 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org # 6.0.x

drm/amd/display: only fill dirty rectangles when PSR is enabled

2022-11-09T23:07:59+00:00

Currently, we are calling fill_dc_dirty_rects() even if PSR isn't
supported by the relevant link in amdgpu_dm_commit_planes(), this is
undesirable especially because when drm.debug is enabled we are printing
messages in fill_dc_dirty_rects() that are only useful for debugging PSR
(and confusing otherwise). So, we can instead limit the filling of dirty
rectangles to only when PSR is enabled.

Reviewed-by: Leo Li 
Signed-off-by: Hamza Mahfooz 
Signed-off-by: Alex Deucher