kernel/linux.git/drivers/gpu/drm/amd/display/dc, branch v5.1.16

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/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

drm/amd/display: half bandwidth for YCbCr420 during validation

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

[ Upstream commit 162f807858d15bde60cf373a3ad46e03200ad9d8 ] [Why] used to be unable to run 4:2:0 if using a dongle because 4k60 bandwidth exceeded dongle caps [How] half pixel clock during comparison to dongle cap. *Could get stuck on black screen on monitor that don't support 420 but will be selecting 420 as preferred mode* Signed-off-by: Martin Leung Reviewed-by: Wenjing Liu Acked-by: Aidan Wood Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Fix Divide by 0 in memory calculations

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

[ Upstream commit 59979bf8be1784ebfc44215031c6c88ca22ae65d ] Check if we get any values equal to 0, and set to 1 if so. Signed-off-by: Murton Liu Reviewed-by: Aric Cyr Acked-by: Bhawanpreet Lakha Acked-by: Sivapiriyan Kumarasamy Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: add pipe lock during stream update

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

[ Upstream commit e6bddf6c67f9a3abf6f1ef75e52bc1cd228dfe4d ] [why] Stream update will adjust both info packets and stream params, need to make sure all things are applied togather. [how] add pipe lock during stream update Signed-off-by: Wenjing Liu Reviewed-by: Jun Lei Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Link train only when link is DP and backend is enabled

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

[ Upstream commit 66acd4418d7de131ef3831e52a8af3d2480e5b15 ] [Why] In certain cases we do link training when we don't have a backend. [How] In dc_link_set_preferred_link_settings(), store preferred link settings first and then verify that the link is DP and the link stream's backend is enabled. If either is false, then we will not do any link retraining. Signed-off-by: Samson Tam Reviewed-by: Aric Cyr Acked-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: fix releasing planes when exiting odm

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

[ Upstream commit bc2193992b00488f5734613ac95b78ef2d2803ab ] Releasing planes should not release the 2nd odm pipe right away, this change leaves us with 2 pipes with null planes and same stream when planes are released during odm. Signed-off-by: Dmytro Laktyushkin Reviewed-by: Tony Cheng Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Prevent cursor hotspot overflow for RV overlay planes

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

[ Upstream commit 6752bea8b03e77c98be7d8d25b0a9d86a00b3cf7 ] [Why] The actual position for the cursor on the screen is essentially: x_out = x - x_plane - x_hotspot y_out = y - y_plane - y_hotspot The register values for cursor position and cursor hotspot need to be greater than zero when programmed, but we also need to subtract off the plane position to display the cursor at the correct position. Since we don't want x or y to be less than zero, we add the plane position as a positive value to x_hotspot or y_hotspot. However, what this doesn't take into account is that the hotspot registers are limited by the maximum cursor size. On DCN10 the cursor hotspot regitsers are masked to 0xFF, so they have a maximum value of 0-255. Values greater this will wrap, causing the cursor to display in the wrong position. In practice this means that for sufficiently large plane positions, the cursor will be drawn twice on the screen, and can cause screen flashes or p-state WARNS depending on what the wrapped value is. So we need a way to remove the value from x_plane and y_plane without exceeding the maximum cursor size. [How] Subtract as much as x_plane/y_plane as possible from x and y and place the remainder in the cursor hotspot register. The value for x_hotspot and y_hotspot can still wrap around but it won't happen in a case where the cursor is actually enabled. The cursor plane needs to intersect at least one pixel of the plane's rectangle to be enabled, so the cursor position + hotspot provided by userspace must always be strictly less than the maximum cursor size for the cursor to actually be enabled. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Sun peng Li Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin