talos-obmc-linux/drivers/gpu, branch v4.4.16

drm/i915: Revert DisplayPort fast link training feature

2016-07-27T16:47:40+00:00

commit 34511dce4b35685d3988d5c8b100d11a068db5bd upstream. It has been found out that in some HW combination the DisplayPort fast link training feature caused screen flickering. Let's revert this feature for now until we can ensure that the feature works for all platforms. This is a manual revert of commits 5fa836a9d859 ("drm/i915: DP link training optimization") and 4e96c97742f4 ("drm/i915: eDP link training optimization"). Fixes: 5fa836a9d859 ("drm/i915: DP link training optimization") Fixes: 4e96c97742f4 ("drm/i915: eDP link training optimization") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393 Reviewed-by: Jani Nikula Signed-off-by: Mika Kahola Signed-off-by: Jani Nikula Link: http://patchwork.freedesktop.org/patch/msgid/1466410226-19543-1-git-send-email-mika.kahola@intel.com (cherry picked from commit 91df09d92ad82c8778ca218097bf827f154292ca) Signed-off-by: Joakim Tjernlund Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Fix error paths when mapping framebuffer

2016-07-27T16:47:35+00:00

commit 58541f7a6458e17ab417321b284f0090f530aa91 upstream. Rather than returning immediately, make sure to unlock the mutexes first. Signed-off-by: Sinclair Yeh Reviewed-by: Charmaine Lee Reported-by: Emil Velikov Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set

2016-07-27T16:47:35+00:00

commit d5f1a291e32309324a8c481ed84b5c118d1360ea upstream. For the Screen Object display unit, we need to reserve a guest-invisible region equal to the size of the framebuffer for the host. This region can only be reserved in VRAM, whereas the guest-visible framebuffer can be reserved in either VRAM or GMR. As such priority should be given to the guest-invisible region otherwise in a limited VRAM situation, we can fail to allocate this region. This patch makes it so that vmw_sou_backing_alloc() is called before the framebuffer is pinned. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Check pin count before attempting to move a buffer

2016-07-27T16:47:35+00:00

commit 4ed7e2242b637bc4af0416e4aa9f945db30fb44a upstream. In certain scenarios, e.g. when fbdev is enabled, we can get into a situation where a vmw_framebuffer_pin() is called on a buffer that is already pinned. When this happens, ttm_bo_validate() will unintentially remove the TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way to actually pin the buffer again. To prevent this, if a buffer is already pinned, then instead of calling ttm_bo_validate(), just make sure the proposed placement is compatible with the existing placement. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Work around mode set failure in 2D VMs

2016-07-27T16:47:35+00:00

commit 7c20d213dd3cd6295bf9162730e7a368af957854 upstream. In a low-memory 2D VM, fbdev can take up a large percentage of available memory, making them unavailable for other DRM clients. Since we do not take fbdev into account when filtering modes, we end up claiming to support more modes than we actually do. As a result, users get a black screen when setting a mode too large for current available memory. In a low-memory VM configuration, users can get a black screen for a mode as low as 1024x768. The current mode filtering mechanism keys off of SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount of surface memory we have. Since this value is a performance suggestion, not a hard limit, and since there should not be much of a performance impact for a 2D VM, rather than filtering out more modes, we will just allow ourselves to exceed the SVGA's performance suggestion. Also changed assumed bpp to 32 from 16 to make sure we can actually support all the modes listed. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Add an option to change assumed FB bpp

2016-07-27T16:47:35+00:00

commit 04319d89fbec72dfd60738003c3813b97c1d5f5a upstream. Offer an option for advanced users who want larger modes at 16bpp. This becomes necessary after the fix: "Work around mode set failure in 2D VMs." Without this patch, there would be no way for existing advanced users to get to a high res mode, and the regression is they will likely get a black screen after a software update on their current VM. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman

drm/ttm: Make ttm_bo_mem_compat available

2016-07-27T16:47:35+00:00

commit 94477bff390aa4612d2332c8abafaae0a13d6923 upstream. There are cases where it is desired to see if a proposed placement is compatible with a buffer object before calling ttm_bo_validate(). Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman

drm: atmel-hlcdc: actually disable scaling when no scaling is required

2016-07-27T16:47:35+00:00

commit 1b7e38b92b0bbd363369f5160f13f4d26140972d upstream. The driver is only enabling scaling, but never disabling it, thus, if you enable the scaling feature once it stays enabled forever. Signed-off-by: Boris Brezillon Reported-by: Alex Vazquez Reviewed-by: Nicolas Ferre Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support") Signed-off-by: Greg Kroah-Hartman

drm: make drm_atomic_set_mode_prop_for_crtc() more reliable

2016-07-27T16:47:35+00:00

commit 6709887c448d1cff51b52d09763c7b834ea5f0be upstream. drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so old data may be left there when a new mode is set, possibly causing odd issues. This patch improves the situation by always clearing the state->mode first. Signed-off-by: Tomi Valkeinen Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm: add missing drm_mode_set_crtcinfo call

2016-07-27T16:47:35+00:00

commit b201e743f42d143f4bcdcb14587caf7cb1d99229 upstream. When setting mode via MODE_ID property, drm_atomic_set_mode_prop_for_crtc() does not call drm_mode_set_crtcinfo() which possibly causes: "[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't calculate constants, dotclock = 0!" Whether the error is seen depends on the previous data in state->mode, as state->mode is not cleared when setting new mode. This patch adds drm_mode_set_crtcinfo() call to drm_mode_convert_umode(), which is called in both legacy and atomic paths. This should be fine as there's no reason to call drm_mode_convert_umode() without also setting the crtc related fields. drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as that is no longer needed. Signed-off-by: Tomi Valkeinen Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman