kernel/linux.git/drivers/gpu/drm/amd/display, branch v4.18.18

drm/amd/display: Signal hw_done() after waiting for flip_done()

2018-11-04T13:51:47+00:00

[ Upstream commit 987bf116445db5d63a5c2ed94c4479687d9c9973 ] In amdgpu_dm_commit_tail(), wait until flip_done() is signaled before we signal hw_done(). [Why] This is to temporarily address a paging error that occurs when a nonblocking commit contends with another commit, particularly in a mirrored display configuration where at least 2 CRTCs are updated. The error occurs in drm_atomic_helper_wait_for_flip_done(), when we attempt to access the contents of new_crtc_state->commit. Here's the sequence for a mirrored 2 display setup (irrelevant steps left out for clarity): **THREAD 1** | **THREAD 2** | Initialize atomic state for flip | | Queue worker | ... | Do work for flip | | Signal hw_done() on CRTC 1 | Signal hw_done() on CRTC 2 | | Wait for flip_done() on CRTC 1 <---- **PREEMPTED BY THREAD 1** Initialize atomic state for cursor | update (1) | | Do cursor update work on both CRTCs | | Clear atomic state (2) | **DONE** | ... | | Wait for flip_done() on CRTC 2 | *ERROR* | The issue starts with (1). When the atomic state is initialized, the current CRTC states are duplicated to be the new_crtc_states, and referenced to be the old_crtc_states. (The new_crtc_states are to be filled with update data.) Some things to note: * Due to the mirrored configuration, the cursor updates on both CRTCs. * At this point, the pflip IRQ has already been handled, and flip_done signaled on all CRTCs. The cursor commit can therefore continue. * The old_crtc_states used by the cursor update are the **same states** as the new_crtc_states used by the flip worker. At (2), the old_crtc_state is freed (*), and the cursor commit completes. We then context switch back to the flip worker, where we attempt to access the new_crtc_state->commit object. This is problematic, as this state has already been freed. (*) Technically, 'state->crtcs[i].state' is freed, which was made to reference old_crtc_state in drm_atomic_helper_swap_state() [How] By moving hw_done() after wait_for_flip_done(), we're guaranteed that the new_crtc_state (from the flip worker's perspective) still exists. This is because any other commit will be blocked, waiting for the hw_done() signal. Note that both the i915 and imx drivers have this sequence flipped already, masking this problem. Signed-off-by: Shirish S Signed-off-by: Leo Li Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: fix use of uninitialized memory

2018-10-03T23:59:05+00:00

[ Upstream commit f3e077d95ca0a016fdf3d6b1e97a9910dfdaff17 ] DML does not calculate chroma values for RQ when surface is not YUV, but DC will unconditionally use the uninitialized values for HW programming. This does not cause visual corruption since HW will ignore garbage chroma values when surface is not YUV, but causes presubmission tests to fail golden value comparison. Signed-off-by: Wesley Chalmers Signed-off-by: Eryk Brol Reviewed-by: Wenjing Liu Acked-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/display/dc/dce: Fix multiple potential integer overflows

2018-10-03T23:59:05+00:00

[ Upstream commit 6f3472a993e7cb63cde5d818dcabc8e42fc03744 ] Add suffix ULL to constant 5 and cast variables target_pix_clk_khz and feedback_divider to uint64_t in order to avoid multiple potential integer overflows and give the compiler complete information about the proper arithmetic to use. Notice that such constant and variables are used in contexts that expect expressions of type uint64_t (64 bits, unsigned). The current casts to uint64_t effectively apply to each expression as a whole, but they do not prevent them from being evaluated using 32-bit arithmetic instead of 64-bit arithmetic. Also, once the expressions are properly evaluated using 64-bit arithmentic, there is no need for the parentheses that enclose them. Addresses-Coverity-ID: 1460245 ("Unintentional integer overflow") Addresses-Coverity-ID: 1460286 ("Unintentional integer overflow") Addresses-Coverity-ID: 1460401 ("Unintentional integer overflow") Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/display: support access ddc for mst branch

2018-09-26T06:39:40+00:00

[ Upstream commit 0a14544661fad1606cc96aece30b2950fd9c4c81 ] [Why] Megachip dockings accesses ddc line through display driver when installing FW. Previously, we would fail every transaction because link attached to mst branch did not have their ddc transaction type set. [How] Set ddc transaction type when mst branch is connected. Signed-off-by: Eric Yang Reviewed-by: Charlene Liu Acked-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Prevent PSR from being enabled if initialization fails

2018-09-19T20:41:35+00:00

[ Upstream commit 9907704174e0ad4ed02766fac4049971e583323d ] [Why] PSR_SET command is sent to the microcontroller in order to initialize parameters needed for PSR feature, such as telling the microcontroller which pipe is driving the PSR supported panel. When this command is skipped or fails, the microcontroller may program the wrong thing if driver tries to enable PSR. [How] If PSR_SET fails, do not set psr_enable flag to indicate the feature is not yet initialized. Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Check if clock source in use before disabling

2018-09-15T07:46:59+00:00

commit ad8960a6cb06c446d0a391ce095f6f28edf36aff upstream. [why] We are disabling clock source while other pipes are still using it, because we don't verify the number of pipes that share it. [how] - Adding a function in resources to return the number of pipes sharing the clock source. - Checking that no one is sharing the clock source before disabling Signed-off-by: Mikita Lipski Reviewed-by: Harry Wentland Acked-by: Leo Li Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Pass connector id when executing VBIOS CT

2018-09-15T07:46:59+00:00

commit 433149130c31de3f63b17b4ce08b45dab208f7e8 upstream. [why] Older ASICs require both phys_id and connector_id to execute bios command table. If we are not passing the right connector_id - it can lead to a black screen. [how] Set connector_obj_id when executing vbios command table Signed-off-by: Mikita Lipski Reviewed-by: Hersen Wu Acked-by: Leo Li Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Report non-DP display as disconnected without EDID

2018-09-15T07:46:58+00:00

commit 01dc285d5cd89b77686d8baef8482c58d7dc3ead upstream. [Why] Some boards seem to have a problem where HPD is high on HDMI even though no display is connected. We don't want to report these as connected. DP spec still requires us to report DP displays as connected when HPD is high but we can't read the EDID in order to go to fail-safe mode. [How] If connector_signal is not DP abort detection if we can't retrieve the EDID. v2: Add Bugzilla and stable Bugzilla: https://bugs.freedesktop.org/107390 Bugzilla: https://bugs.freedesktop.org/106846 Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Acked-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Use requested HDMI aspect ratio

2018-09-15T07:46:58+00:00

commit e11d41472a50742c16d53c968e143fb498fa482f upstream. [Why] The DRM mode's HDMI picture aspect ratio field was never saved in dc_stream's timing struct. This causes us to mistake a new stream to have the same timings as the old, even though the user has requested a different aspect ratio. [How] Save DRM's aspect ratio field within dc_stream's timing struct. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107153 Signed-off-by: Leo (Sunpeng) Li Reviewed-by: Mikita Lipski Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/display: update clk for various HDMI color depths

2018-09-15T07:46:58+00:00

commit 81aca8e75c1b046865fb2badef95a0dcff6f73de upstream. [why] When programming tonga's connector's backend we didn't take in account that HDMI's colour depth might be more than 8bpc therefore we need to add a switch statement that would adjust the pixel clock accordingly. [how] Add a switch statement updating clock by its appropriate coefficient. Signed-off-by: Mikita Lipski Reviewed-by: Charlene Liu Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman