linux-stable.git/drivers/gpu/drm/amd/display, branch v5.8.2

drm/amd/display: allow query ddc data over aux to be read only operation

2020-08-19T06:26:19+00:00

[ Upstream commit 26b4750d6cf84cb2b3f0a84c9b345e7b71886410 ]

[why]
Two issues:
1. Add read only operation support for query ddc data over aux.
2. Fix a bug where if read size is multiple of 16,
mot of the last read transaction will not be set to 0.

Signed-off-by: Wenjing Liu 
Reviewed-by: Jun Lei 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu/display: properly guard the calls to swSMU functions

2020-08-19T06:26:19+00:00

[ Upstream commit 4072327a2622af8688b88f5cd0a472136d3bf33d ]

It's only applicable on newer asics.  We could end up here when
using DC on older asics like SI or KV.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1170
Reviewed-by: Evan Quan 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu/display bail early in dm_pp_get_static_clocks

2020-08-19T06:26:19+00:00

[ Upstream commit 376814f5fcf1aadda501d1413d56e8af85d19a97 ]

If there are no supported callbacks.  We'll fall back to the
nominal clocks.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1170
Reviewed-by: Evan Quan 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Improve DisplayPort monitor interop

2020-08-19T06:26:18+00:00

[ Upstream commit eec3303de3378cdfaa0bb86f43546dbbd88f94e2 ]

[Why]
DC is very fast at link training and stream enablement
which causes issues such as blackscreens for non-compliant
monitors.

[How]
After debugging with scaler vendors we implement the
minimum delays at the necessary locations to ensure
the monitor does not hang.  Delays are generic due to
lack of IEEE OUI information on the failing displays.

Signed-off-by: Aric Cyr 
Reviewed-by: Wenjing Liu 
Acked-by: Qingqing Zhuo 
Acked-by: Tony Cheng 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Clear dm_state for fast updates

2020-07-30T15:02:10+00:00

This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
are requested and the second one finishes before the first. Essentially,
this bug occurs when the following sequence of events happens:

1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.

2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.

3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.

4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.

Since this bug has only been spotted with fast commits, this patch fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found,
removing the dm_state should not have any consequences in fast updates.

This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for fast updates")
Reported-by: Duncan <1i5t5.duncan@cox.net>
Signed-off-by: Mazin Rezk 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amd/display: handle failed allocation during stream construction

2020-07-14T19:14:15+00:00

[Why]
Failing to allocate a transfer function during stream construction leads
to a null pointer dereference

[How]
Handle the failed allocation by failing the stream construction

Cc: stable@vger.kernel.org
Signed-off-by: Josip Pavic 
Reviewed-by: Aric Cyr 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: OLED panel backlight adjust not work with external display connected

2020-07-14T19:13:15+00:00

[Why]
amdgpu_dm->backlight_caps is for single eDP only. the caps are upddated
for very connector. Real eDP caps will be overwritten by other external
display. For OLED panel, caps->aux_support is set to 1 for OLED pnael.
after external connected, caps+.aux_support is set to 0. This causes
OLED backlight adjustment not work.

[How]
within update_conector_ext_caps, backlight caps will be updated only for
eDP connector.

Cc: stable@vger.kernel.org
Signed-off-by: hersen wu 
Reviewed-by: Nicholas Kazlauskas 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amdgpu/display: create fake mst encoders ahead of time (v4)

2020-07-14T19:11:07+00:00

Prevents a warning in the MST create connector case.

v2: create global fake encoders rather per connector fake encoders
to avoid running out of encoder indices.

v3: use the actual number of crtcs on the asic rather than the max
to conserve encoders.

v4: v3 plus missing hunk I forgot to git add.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1108
Fixes: c6385e503aeaf9 ("drm/amdgpu: drop legacy drm load and unload callbacks")
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org # 5.7.x

drm/amd/display: add dmcub check on RENOIR

2020-07-09T18:42:37+00:00

RENOIR loads dmub fw not dmcu, check dmcu only will prevent loading iram,
it breaks backlight control.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208277
Acked-by: Alex Deucher 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Aaron Ma 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amd/display: Only revalidate bandwidth on medium and fast updates

2020-07-01T02:15:12+00:00

[Why]
Changes that are fast don't require updating DLG parameters making
this call unnecessary. Considering this is an expensive call it should
not be done on every flip.

DML touches clocks, p-state support, DLG params and a few other DC
internal flags and these aren't expected during fast. A hang has been
reported with this change when called on every flip which suggests that
modifying these fields is not recommended behavior on fast updates.

[How]
Guard the validation to only happen if update type isn't FAST.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191
Fixes: a24eaa5c51255b ("drm/amd/display: Revalidate bandwidth before commiting DC updates")
Signed-off-by: Nicholas Kazlauskas 
Acked-by: Alex Deucher 
Reviewed-by: Roman Li 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org