user/sven/linux.git/drivers/gpu/drm, branch v4.4.118

drm/gma500: remove helper function

2018-02-25T10:03:52Z

commit db9b60400f9253c25ae639797df2d0ff7a35d9d8 upstream. We were getting build warning about: drivers/gpu/drm/gma500/mdfld_dsi_output.c:407:2: warning: initialization from incompatible pointer type The callback to dpms was pointing to a helper function which had a return type of void, whereas the callback should point to a function which has a return type of int. On closer look it turned out that we do not need the helper function since if we call drm_helper_connector_dpms() directly, the first check that drm_helper_connector_dpms() does is: if (mode == connector->dpms) Signed-off-by: Sudip Mukherjee Link: http://patchwork.freedesktop.org/patch/msgid/1454393155-13142-1-git-send-email-sudipm.mukherjee@gmail.com Acked-by: Patrik Jakobsson Signed-off-by: Daniel Vetter [arnd: rebased to 4.4] Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

drm/gma500: Sanity-check pipe index

2018-02-25T10:03:49Z

commit 4f250706211cdb949f7580d4fe4dd1fd646de693 upstream. If the DSI output isn't connected, then mdfld_dsi_encoder_get_pipe() will return -1. The mdfld_dsi_dp_mode_set() function doesn't properly check for this condition and causes the following compiler warnings: CC drivers/gpu/drm/gma500/mdfld_dsi_dpi.o drivers/gpu/drm/gma500/mdfld_dsi_dpi.c: In function ‘mdfld_dsi_dpi_mode_set’: drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:828:35: warning: array subscript is below array bounds [-Warray-bounds] u32 pipeconf = dev_priv->pipeconf[pipe]; ^ drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:829:33: warning: array subscript is below array bounds [-Warray-bounds] u32 dspcntr = dev_priv->dspcntr[pipe]; ^ Fix this by checking for a valid pipe before indexing the pipeconf and dspcntr arrays. Cc: Patrik Jakobsson Reviewed-by: Patrik Jakobsson Signed-off-by: Thierry Reding Signed-off-by: Boris Brezillon Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-2-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/nouveau: hide gcc-4.9 -Wmaybe-uninitialized

2018-02-25T10:03:48Z

commit b74c0a9969f25217a5e5bbcac56a11bee16718d3 upstream. gcc-4.9 notices that the validate_init() function returns unintialized data when called with a zero 'nr_buffers' argument, when called with the -Wmaybe-uninitialized flag: drivers/gpu/drm/nouveau/nouveau_gem.c: In function ‘validate_init.isra.6’: drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] However, the only caller of this function always passes a nonzero argument, and gcc-6 is clever enough to take this into account and not warn about it any more. Adding an explicit initialization to -EINVAL here is correct even if the caller changed, and it avoids the warning on gcc-4.9 as well. Signed-off-by: Arnd Bergmann Reviewed-By: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: use *_32_bits() macros

2018-02-25T10:03:48Z

commit 0e7c875d1ae9dcf4d8c6018a45e5529feaef8956 upstream. Use the upper_32_bits() macro instead of the four line equivalent that triggers a GCC warning on 32 bits x86: drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_header_submit': drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:297:25: warning: right shift count >= width of type [-Wshift-count-overflow] val = (header->handle >> 32); ^ And use the lower_32_bits() macro instead of and-ing with a 32 bits mask. Signed-off-by: Paul Bolle Acked-by: Joe Perches Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1457000770-2317-1-git-send-email-pebolle@tiscali.nl Signed-off-by: Greg Kroah-Hartman

drm/armada: fix leak of crtc structure

2018-02-25T10:03:41Z

[ Upstream commit 33cd3c07a976e11c3c4cc6b0b3db6760ad1590c5 ] Fix the leak of the CRTC structure in the failure paths of armada_drm_crtc_create(). Signed-off-by: Russell King Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all

2018-02-25T10:03:35Z

commit d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 upstream. To acquire all modeset locks requires a ww_ctx to be allocated. As this is the legacy path and the allocation small, to reduce the changes required (and complex untested error handling) to the legacy drivers, we simply assume that the allocation succeeds. At present, it relies on the too-small-to-fail rule, but syzbot found that by injecting a failure here we would hit the WARN. Document that this allocation must succeed with __GFP_NOFAIL. Signed-off-by: Chris Wilson Cc: Daniel Vetter Reported-by: syzbot Signed-off-by: Daniel Vetter Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171031115535.15166-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman

drm/radeon: adjust tested variable

2018-02-22T14:44:59Z

commit 3a61b527b4e1f285d21b6e9e623dc45cf8bb391f upstream. Check the variable that was most recently initialized. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x, y, f, g, e, m; statement S1,S2,S3,S4; @@ x = f(...); if (\(<+...x...+>\&e\)) S1 else S2 ( x = g(...); | m = g(...,&x,...); | y = g(...); *if (e) S3 else S4 ) // Signed-off-by: Julia Lawall Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm: rcar-du: Fix race condition when disabling planes at CRTC stop

2018-02-16T19:09:37Z

commit 641307df71fe77d7b38a477067495ede05d47295 upstream. When stopping the CRTC the driver must disable all planes and wait for the change to take effect at the next vblank. Merely calling drm_crtc_wait_one_vblank() is not enough, as the function doesn't include any mechanism to handle the race with vblank interrupts. Replace the drm_crtc_wait_one_vblank() call with a manual mechanism that handles the vblank interrupt race. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: thongsyho Signed-off-by: Nhan Nguyen Signed-off-by: Greg Kroah-Hartman

drm: rcar-du: Use the VBK interrupt for vblank events

2018-02-16T19:09:37Z

commit cbbb90b0c084d7dfb2ed8e3fecf8df200fbdd2a0 upstream. When implementing support for interlaced modes, the driver switched from reporting vblank events on the vertical blanking (VBK) interrupt to the frame end interrupt (FRM). This incorrectly divided the reported refresh rate by two. Fix it by moving back to the VBK interrupt. Fixes: 906eff7fcada ("drm: rcar-du: Implement support for interlaced modes") Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: thongsyho Signed-off-by: Nhan Nguyen Signed-off-by: Greg Kroah-Hartman

drm/omap: Fix error handling path in 'omap_dmm_probe()'

2018-02-03T16:04:29Z

[ Upstream commit 8677b1ac2db021ab30bb1fa34f1e56ebe0051ec3 ] If we don't find a matching device node, we must free the memory allocated in 'omap_dmm' a few lines above. Fixes: 7cb0d6c17b96 ("drm/omap: fix TILER on OMAP5") Signed-off-by: Christophe JAILLET Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman