kernel/linux.git/drivers/gpu/drm/amd, branch v5.1.10

drm/amd/display: Use plane->color_space for dpp if specified

2019-06-15T09:53:02+00:00

[ Upstream commit a1e07ba89d49581471d64c48152dbe03b42bd025 ] [Why] The input color space for the plane was previously ignored even if it was set. If a limited range YUV format was given to DC then the wrong color transformation matrix was being used since DC assumed that it was full range instead. [How] Respect the given color_space format for the plane if it isn't COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM didn't specify. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Sun peng Li Acked-by: Aric Cyr Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: disable link before changing link settings

2019-06-15T09:53:02+00:00

[ Upstream commit 15ae3b28f8ca406b449d36d36021e96b66aedb5d ] [Why] If link is already enabled at a different rate (for example 5.4 Gbps) then calling VBIOS command table to switch to a new rate (for example 2.7 Gbps) will not take effect. This can lead to link training failure to occur. [How] If the requested link rate is different than the current link rate, the link must be disabled in order to re-enable at the new link rate. In today's logic it is currently only impacting eDP since DP connection types will always disable the link during display detection, when initial link verification occurs. Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Leo Li Acked-by: Tony Cheng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd: fix fb references in async update

2019-06-11T10:19:23+00:00

commit 332af874db929f92931727bfe191b2c666438c81 upstream. Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: # v4.20+ Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates") Suggested-by: Boris Brezillon Signed-off-by: Helen Koike Reviewed-by: Nicholas Kazlauskas Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-3-helen.koike@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)

2019-06-11T10:19:22+00:00

commit ce0e22f5d886d1b56c7ab4347c45b9ac5fcc058d upstream. [What] vce ring test fails consistently during resume in s3 cycle, due to mismatch read & write pointers. On debug/analysis its found that rptr to be compared is not being correctly updated/read, which leads to this failure. Below is the failure signature: [drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed [drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block failed -110 [drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110). [How] fetch rptr appropriately, meaning move its read location further down in the code flow. With this patch applied the s3 failure is no more seen for >5k s3 cycles, which otherwise is pretty consistent. V2: remove reduntant fetch of rptr Signed-off-by: Louis Li Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Add ASICREV_IS_PICASSO

2019-06-11T10:19:21+00:00

commit ada637e70f96862ff5ba20a169506b58cf567db9 upstream. [WHY] We only want to load DMCU FW on Picasso and Raven 2, not on Raven 1. Signed-off-by: Harry Wentland Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/soc15: skip reset on init

2019-06-11T10:19:21+00:00

commit 5887a59961e2295c5b02f39dbc0ecf9212709b7b upstream. Not necessary on soc15 and breaks driver reload on server cards. Acked-by: Amber Lin Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-in

2019-06-11T10:19:21+00:00

commit bdb1ccb080dafc1b4224873a5b759ff85a7d1c10 upstream. In amdgpu_atif_handler, when hotplug event received, remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check. This bit's check will cause missing system resume. Signed-off-by: Aaron Liu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/psp: move psp version specific function pointers to early_init

2019-06-11T10:19:20+00:00

commit 9d6fea5744d6798353f37ac42a8a653a2607ca69 upstream. In case we need to use them for GPU reset prior initializing the asic. Fixes a crash if the driver attempts to reset the GPU at driver load time. Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Reset planes that were disabled in init_pipes

2019-05-31T13:43:58+00:00

[ Upstream commit 4bc46da4a3aeeb4d55e83dd276cf72756e908286 ] [Why] Seamless boot tries to reuse planes that were enabled for the first commit applied. In the case where Raven is booting with two monitors connected and the first commit contains two streams the screen corruption would occur because the second stream was trying to re-use a tg and plane that weren't previously enabled. The state on the first commit looks something like the following: TG0: enabled=1 TG1: enabled=0 TG2: enabled=0 TG3: enabled=0 New state: pipe=0, stream=0, plane=0, new_tg=0 New state: pipe=1, stream=1, plane=1, new_tg=1 New state: pipe=2, stream=NULL, plane=NULL, new_tg=NULL New state: pipe=3, stream=NULL, plane=NULL, new_tg=NULL Only one plane/tg is setup before we enter accelerated mode so we really want to disabling everything but that first plane. [How] Check if the stream is not NULL and if the tg is enabled before deciding whether to skip the plane disable. Also ensure we're also disabling on the current state's pipe_ctx so we don't overwrite the fields in the new pending state. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Anthony Koo Acked-by: Harry Wentland Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Fix exception from AUX acquire failure

2019-05-31T13:43:58+00:00

[ Upstream commit dcf1a988678e2e39ce2b4115b8ce14d208c8c481 ] [Why] AUX arbitration occurs between SW and FW components. When AUX acquire fails, it causes engine->ddc to be NULL, which leads to an exception when we try to release the AUX engine. [How] When AUX engine acquire fails, it should return from the function without trying to continue the operation. The upper level will determine if it wants to retry. i.e. dce_aux_transfer_with_retries will be used and retry. Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin