kernel/linux.git/drivers/gpu/drm/amd/display/amdgpu_dm, branch v5.2.13

drm/amd/display: Always allocate initial connector state state

2019-07-31T05:24:38+00:00

[ Upstream commit f04bee34d6e35df26cbb2d65e801adfd0d8fe20d ] [Why] Unlike our regular connectors, MST connectors don't start off with an initial connector state. This causes a NULL pointer dereference to occur when attaching the bpc property since it tries to modify the connector state. We need an initial connector state on the connector to avoid the crash. [How] Use our reset helper to allocate an initial state and reset the values to their defaults. We were already doing this before, just not for MST connectors. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Reset planes for color management changes

2019-07-31T05:24:35+00:00

[ Upstream commit 7316c4ad299663a16ca9ce13e5e817b4ca760809 ] [Why] For commits with allow_modeset=false and CRTC degamma changes the planes aren't reset. This results in incorrect rendering. [How] Reset the planes when color management has changed on the CRTC. Technically this will include regamma changes as well, but it doesn't really after legacy userspace since those commit with allow_modeset=true. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Harry Wentland Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Fill plane attrs only for valid pxl format

2019-07-31T05:24:32+00:00

[ Upstream commit 1894478ad1f8fd7366edc5cee49ee9caea0e3d52 ] [Why] In fill_plane_buffer_attributes() we calculate chroma/luma assuming that the surface_pixel_format is always valid. If it's not the case, there's a risk of divide by zero error. [How] Check if format valid before calculating pixel format attributes Signed-off-by: Roman Li Reviewed-by: David Francis Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Disable cursor when offscreen in negative direction

2019-07-31T05:24:32+00:00

[ Upstream commit e371e19c10a264bd72c2ff1d21e2167b994710d1 ] [Why] When x or y is negative we set the x and y values to 0 and compensate with a positive cursor hotspot in DM since DC expects positive cursor values. When x or y is less than or equal to the maximum cursor width or height the cursor hotspot is clamped so the hotspot doesn't exceed the cursor size: if (x < 0) { xorigin = min(-x, amdgpu_crtc->max_cursor_width - 1); x = 0; } if (y < 0) { yorigin = min(-y, amdgpu_crtc->max_cursor_height - 1); y = 0; } This incorrectly forces the cursor to be at least 1 pixel on the screen in either direction when x or y is sufficiently negative. [How] Just disable the cursor when it goes far enough off the screen in one of these directions. This fixes kms_cursor_crc@cursor-256x256-offscreen. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Sun peng Li Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd: fix fb references in async update

2019-06-04T08:13:17+00:00

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

drm/amd/display: Don't load DMCU for Raven 1 (v2)

2019-05-24T15:16:36+00:00

[WHY] Some early Raven boards had a bad SBIOS that doesn't play nicely with the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU load but that doesn't seem to be the case. We've still seen reports of users unable to boot their systems at all. [HOW] Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso. v2: Fix ifdef (Alex) Signed-off-by: Harry Wentland Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

Revert "drm/amd/display: Don't load DMCU for Raven 1"

2019-05-24T09:56:50+00:00

This reverts commit 55143dc23ca4792868ea8c17bce65ca7b3d3e8c4. This causes build breakags with some Kconfigs so revert for now. Fixes: 55143dc23ca4 ("drm/amd/display: Don't load DMCU for Raven 1") Signed-off-by: Dave Airlie

drm/amd/display: Don't load DMCU for Raven 1

2019-05-20T17:42:40+00:00

[WHY] Some early Raven boards had a bad SBIOS that doesn't play nicely with the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU load but that doesn't seem to be the case. We've still seen reports of users unable to boot their systems at all. [HOW] Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso. Signed-off-by: Harry Wentland Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/amd/display: Use long for signed error code checks in commit planes

2019-05-06T14:36:48+00:00

[Why] The type of 'r' is uint32_t and the return codes for both: - reservation_object_wait_timeout_rcu - amdgpu_bo_reserve ...are signed. While it works for the latter since the check is done on != 0 it doesn't work for the former since we check <= 0. [How] Make 'r' a long in commit planes so we're not doing any unsigned/signed conversion here in the first place. v2: use long instead of int (Christian) Reported-by: Dan Carpenter Signed-off-by: Nicholas Kazlauskas Reviewed-by: Christian König Signed-off-by: Alex Deucher

Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-next

2019-05-03T00:31:07+00:00

- SR-IOV fixes - Raven flickering fix - Misc spelling fixes - Vega20 power fixes - Freesync improvements - DC fixes Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20190502193020.3562-1-alexander.deucher@amd.com