user/sven/linux.git/drivers/gpu, branch v5.4.3

drm/mcde: Fix an error handling path in 'mcde_probe()'

2019-12-13T07:43:29Z

[ Upstream commit 15c665bb4637310bc8ce5f357b6a6e5a8aafc7c1 ] If we don't find any matching components, we should go through the error handling path, in order to free some resources. Fixes: ca5be902a87d ("drm/mcde: Fix uninitialized variable") Signed-off-by: Christophe JAILLET Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20190822211518.5578-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin

drm/i810: Prevent underflow in ioctl

2019-12-13T07:42:56Z

commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream. The "used" variables here come from the user in the ioctl and it can be negative. It could result in an out of bounds write. Signed-off-by: Dan Carpenter Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm: damage_helper: Fix race checking plane->state->fb

2019-12-13T07:42:55Z

commit 354c2d310082d1c384213ba76c3757dd3cd8755d upstream. Since the dirtyfb ioctl doesn't give us any hints as to which plane is scanning out the fb it's marking as damaged, we need to loop through planes to find it. Currently we just reach into plane state and check, but that can race with another commit changing the fb out from under us. This patch locks the plane before checking the fb and will release the lock if the plane is not displaying the dirty fb. Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb") Cc: Rob Clark Cc: Deepak Rawat Cc: Daniel Vetter Cc: Thomas Hellstrom Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.0+ Reported-by: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190904202938.110207-1-sean@poorly.run Signed-off-by: Greg Kroah-Hartman

drm/msm: fix memleak on release

2019-12-13T07:42:54Z

commit a64fc11b9a520c55ca34d82e5ca32274f49b6b15 upstream. If a process is interrupted while accessing the "gpu" debugfs file and the drm device struct_mutex is contended, release() could return early and fail to free related resources. Note that the return value from release() is ignored. Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state") Cc: stable # 4.18 Cc: Jordan Crouse Cc: Rob Clark Reviewed-by: Rob Clark Signed-off-by: Johan Hovold Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191010131333.23635-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

Merge tag 'drm-intel-fixes-2019-11-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

2019-11-22T00:29:52Z

- Fix kernel oops on dumb_create ioctl on no crtc situation - Fix bad ugly colored flash on VLV/CHV related to gamma LUT update - Fix unity of the frequencies reported on PMU - Fix kernel oops on set_page_dirty using better locks around it - Protect the request pointer with RCU to prevent it being freed while we might need still - Make pool objects read-only - Restore physical addresses for fb_map to avoid corrupted page table Signed-off-by: Dave Airlie From: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20191121165339.GA23920@intel.com

drm/i915/fbdev: Restore physical addresses for fb_mmap()

2019-11-21T08:09:22Z

fbdev uses the physical address of our framebuffer for its fb_mmap() routine. While we need to adapt this address for the new io BAR, we have to fix v5.4 first! The simplest fix is to restore the smem back to v5.3 and we will then probably have to implement our fbops->fb_mmap() callback to handle local memory. Reported-by: Neil MacLeod Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256 Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base") Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Maarten Lankhorst Tested-by: Neil MacLeod Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk (cherry picked from commit abc5520704ab438099fe352636b30b05c1253bea) Signed-off-by: Joonas Lahtinen (cherry picked from commit 9faf5fa4d3dad3b0c0fa6e67689c144981a11c27) Signed-off-by: Rodrigo Vivi

Revert "drm/amd/display: enable S/G for RAVEN chip"

2019-11-20T23:40:21Z

This reverts commit 1c4259159132ae4ceaf7c6db37a6cf76417f73d9. S/G display is not stable with the IOMMU enabled on some platforms. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523 Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/amdgpu: disable gfxoff on original raven

2019-11-20T23:40:21Z

There are still combinations of sbios and firmware that are not stable. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204689 Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/amdgpu: disable gfxoff when using register read interface

2019-11-20T23:40:21Z

When gfxoff is enabled, accessing gfx registers via MMIO can lead to a hang. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497 Acked-by: Xiaojie Yuan Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/amd/powerplay: correct fine grained dpm force level setting

2019-11-20T23:40:21Z

For fine grained dpm, there is only two levels supported. However to reflect correctly the current clock frequency, there is an intermediate level faked. Thus on forcing level setting, we need to treat level 2 correctly as level 1. Signed-off-by: Evan Quan Reviewed-by: Kevin Wang Signed-off-by: Alex Deucher