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

drm/amd/display: ensure async flips are only accepted for fast updates

2023-09-13T07:42:26+00:00

commit a7c0cad0dc060bb77e9c9d235d68441b0fc69507 upstream. We should be checking to see if async flips are supported in amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also, async flipping isn't supported if a plane's framebuffer changes memory domains during an atomic commit. So, move the check from dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if the memory domain has changed in amdgpu_dm_atomic_check(). Cc: stable@vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2733 Fixes: c1e18c44dc7f ("drm/amd/display: only accept async flips for fast updates") Reviewed-by: Harry Wentland Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Cc: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

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

2023-09-13T07:42:20+00:00

[ Upstream commit 11b92df8a2f7f4605ccc764ce6ae4a72760674df ] This reverts commit 4243c84aa082d8fba70c45f48eb2bb5c19799060. Enables freesync video by default, since the hang and corruption issue on eDP panels are now fixed. Acked-by: Stylon Wang Signed-off-by: Aurabindo Pillai Reviewed-by: Rodrigo Siqueira Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: fix access hdcp_workqueue assert

2023-08-23T15:52:27+00:00

[ Upstream commit cdff36a0217aadf5cbc167893ad1c0da869619cb ] [Why] hdcp are enabled for asics from raven. for old asics which hdcp are not enabled, hdcp_workqueue are null. some access to hdcp work queue are not guarded with pointer check. [How] add hdcp_workqueue pointer check before access workqueue. Reviewed-by: Bhawanpreet Lakha Acked-by: Qingqing Zhuo Signed-off-by: Hersen Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: phase3 mst hdcp for multiple displays

2023-08-23T15:52:27+00:00

[ Upstream commit e8fd3eeb5e8711af39b00642da06474e52f4780c ] [Why] multiple display hdcp are enabled within event_property_validate, event_property_update by looping all displays on mst hub. when one of display on mst hub in unplugged or disabled, hdcp are disabled for all displays on mst hub within hdcp_reset_display by looping all displays of mst link. for displays still active, their encryption status are off. kernel driver will not run hdcp authentication again. therefore, hdcp are not enabled automatically. [How] within is_content_protection_different, check drm_crtc_state changes of all displays on mst hub, if need, triger hdcp_update_display to re-run hdcp authentication. Acked-by: Aurabindo Pillai Signed-off-by: hersen wu Reviewed-by: Bhawanpreet Lakha Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Stable-dep-of: cdff36a0217a ("drm/amd/display: fix access hdcp_workqueue assert") Signed-off-by: Sasha Levin

drm/amd/display: save restore hdcp state when display is unplugged from mst hub

2023-08-23T15:52:27+00:00

[ Upstream commit 82986fd631fa04bcedaefe11a6b3767601cbe84f ] [Why] connector hdcp properties are lost after display is unplgged from mst hub. connector is destroyed with dm_dp_mst_connector_destroy. when display is plugged back, hdcp is not desired and it wouldnt be enabled. [How] save hdcp properties into hdcp_work within amdgpu_dm_atomic_commit_tail. If the same display is plugged back with same display index, its hdcp properties will be retrieved from hdcp_work within dm_dp_mst_get_modes. Acked-by: Aurabindo Pillai Signed-off-by: hersen wu Reviewed-by: Bhawanpreet Lakha Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Stable-dep-of: cdff36a0217a ("drm/amd/display: fix access hdcp_workqueue assert") Signed-off-by: Sasha Levin

drm/amd: Disable S/G for APUs when 64GB or more host memory

2023-08-16T16:27:22+00:00

commit 08fffa74d9772d9538338be3f304006c94dde6f0 upstream. Users report a white flickering screen on multiple systems that is tied to having 64GB or more memory. When S/G is enabled pages will get pinned to both VRAM carve out and system RAM leading to this. Until it can be fixed properly, disable S/G when 64GB of memory or more is detected. This will force pages to be pinned into VRAM. This should fix white screen flickers but if VRAM pressure is encountered may lead to black screens. It's a trade-off for now. Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)") Cc: Hamza Mahfooz Cc: Roman Li Cc: # 6.1.y: bf0207e172703 ("drm/amdgpu: add S/G display parameter") Cc: # 6.4.y Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2735 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2354 Signed-off-by: Mario Limonciello Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: add S/G display parameter

2023-08-16T16:27:22+00:00

commit bf0207e1727031798f300afa17f9bbeceac6da87 upstream. Some users have reported flickerng with S/G display. We've tried extensively to reproduce and debug the issue on a wide variety of platform configurations (DRAM bandwidth, etc.) and a variety of monitors, but so far have not been able to. We disabled S/G display on a number of platforms to address this but that leads to failure to pin framebuffers errors and blank displays when there is memory pressure or no displays at all on systems with limited carveout (e.g., Chromebooks). Add a option to disable this as a debugging option as a way for users to disable this, depending on their use case, and for us to help debug this further. v2: fix typo Reviewed-by: Harry Wentland Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Ensure that planes are in the same order

2023-08-11T10:08:25+00:00

commit bb46a6a9bab134b9d15043ea8fa9d6c276e938b8 upstream. The function dc_update_planes_and_stream handles multiple cases where DC needs to remove and add planes in the commit tail phase. After Linux started to use this function, some of the IGT kms_plane started to fail; one good example to illustrate why the new sequence regressed IGT is the subtest plane-position-hole which has the following diagram as a template: +--------------------+ +-----------------------+ | +-----+ | | +-----+ | | | | | | | +-----+ | | | +--+ | ==> | | | | | | | |__| | | +-|---+ | | | | | +-----+ | | | | | +--------------------+ +-----------------------+ (a) Final image (b) Composed image IGT expects image (a) as the final result of two plane compositions as described in figure (b). After the migration to the new sequence, the last plane order is changed, and DC generates the following image: +---------------------+ | +-----+ | | | | | | | | | | +-----+ | | | +---------------------+ Notice that the generated image by DC is different because the small square that should be composed on top of the primary plane is below the primary plane. For this reason, the CRC will mismatch with the expected value. Since the function dc_add_all_planes_for_stream re-append all the new planes back to the dc_validation_set, this commit ensures that the original sequence is maintained. After this change, all CI tests in all ASICs start to pass again. Reviewed-by: Harry Wentland Acked-by: Qingqing Zhuo Suggested-by: Melissa Wen Signed-off-by: Rodrigo Siqueira Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Write to correct dirty_rect

2023-08-03T08:24:18+00:00

commit 751281c55579f0cb0e56c9797d4663f689909681 upstream. When FB_DAMAGE_CLIPS are provided in a non-MPO scenario, the loop does not use the counter i. This causes the fill_dc_dity_rect() to always fill dirty_rects[0], causing graphical artifacts when a damage clip aware DRM client sends more than 1 damage clip. Instead, use the flip_addrs->dirty_rect_count which is incremented by fill_dc_dirty_rect() on a successful fill. Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2453 Signed-off-by: Benjamin Cheng Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman

drm/amd/display: perform a bounds check before filling dirty rectangles

2023-08-03T08:24:18+00:00

commit af22d6a869cc26b519bfdcd54293c53f2e491870 upstream. Currently, it is possible for us to access memory that we shouldn't. Since, we acquire (possibly dangling) pointers to dirty rectangles before doing a bounds check to make sure we can actually accommodate the number of dirty rectangles userspace has requested to fill. This issue is especially evident if a compositor requests both MPO and damage clips at the same time, in which case I have observed a soft-hang. So, to avoid this issue, perform the bounds check before filling a single dirty rectangle and WARN() about it, if it is ever attempted in fill_dc_dirty_rect(). Cc: stable@vger.kernel.org # 6.1+ Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support") Reviewed-by: Leo Li Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman