summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2017-08-25drm/amdgpu: save list length when fence is signaledChunming Zhou1-7/+6
commit 7a7c286d07f9c704e8fd11dd960bf421cc67b66b upstream. update the list first to avoid redundant checks. Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-25drm/i915: Perform an invalidate prior to executing golden renderstateChris Wilson1-0/+4
commit a0125a932e917cb507b682cb66645efdca1f8cab upstream. As we may have just bound the renderstate into the GGTT for execution, we need to ensure that the GTT TLB are also flushed. On snb-gt2, this would cause a random GPU hang at the start of a new context (e.g. boot) and on snb-gt1, it was causing the renderstate batch to take ~10s. It was the GPU hang that revealed the truth, as the CS gleefully executed beyond the end of the golden renderstate batch, a good indicator for a GTT TLB miss. Fixes: 20fe17aa52dc ("drm/i915: Remove redundant TLB invalidate on switching contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808131904.1385-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.12-rc1+ (cherry picked from commit 802673d66f8a6ded5d2689d597853c7bb3a70163) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-16drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lutMaarten Lankhorst1-0/+1
commit 5279fc7724ae3a82c9cfe5b09c1fb07ff0e41056 upstream. bdw_load_gamma_lut is writing beyond the array to the maximum value. The intend of the function is to clamp values > 1 to 1, so write the intended color to the max register. This fixes the following KASAN warning: [ 197.020857] [IGT] kms_pipe_color: executing [ 197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0 [ 197.078989] ================================================================== [ 197.079127] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079188] Read of size 2 at addr ffff8800d38db150 by task kms_pipe_color/1839 [ 197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G U 4.13.0-rc1-patser+ #5211 [ 197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015 [ 197.079220] Call Trace: [ 197.079230] dump_stack+0x68/0x9e [ 197.079239] print_address_description+0x6f/0x250 [ 197.079251] kasan_report+0x216/0x370 [ 197.079374] ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079451] ? gen8_write16+0x4e0/0x4e0 [i915] [ 197.079460] __asan_report_load2_noabort+0x14/0x20 [ 197.079535] bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079612] broadwell_load_luts+0x1df/0x550 [i915] [ 197.079690] intel_color_load_luts+0x7b/0x80 [i915] [ 197.079764] intel_begin_crtc_commit+0x138/0x760 [i915] [ 197.079783] drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820 [drm_kms_helper] [ 197.079859] ? intel_pre_plane_update+0x571/0x580 [i915] [ 197.079937] intel_update_crtc+0x238/0x330 [i915] [ 197.080016] intel_update_crtcs+0x10f/0x210 [i915] [ 197.080092] intel_atomic_commit_tail+0x1552/0x3340 [i915] [ 197.080101] ? _raw_spin_unlock+0x3c/0x40 [ 197.080110] ? __queue_work+0xb40/0xbf0 [ 197.080188] ? skl_update_crtcs+0xc00/0xc00 [i915] [ 197.080195] ? trace_hardirqs_on+0xd/0x10 [ 197.080269] ? intel_atomic_commit_ready+0x128/0x13c [i915] [ 197.080329] ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915] [ 197.080336] ? debug_object_activate+0x39e/0x580 [ 197.080397] ? i915_sw_fence_await+0x30/0x30 [i915] [ 197.080409] ? __might_sleep+0x15b/0x180 [ 197.080483] intel_atomic_commit+0x944/0xa70 [i915] [ 197.080490] ? refcount_dec_and_test+0x11/0x20 [ 197.080567] ? intel_atomic_commit_tail+0x3340/0x3340 [i915] [ 197.080597] ? drm_atomic_crtc_set_property+0x303/0x580 [drm] [ 197.080674] ? intel_atomic_commit_tail+0x3340/0x3340 [i915] [ 197.080704] drm_atomic_commit+0xd7/0xe0 [drm] [ 197.080722] drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper] [ 197.080749] drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm] [ 197.080775] drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm] [ 197.080783] ? __might_fault+0x104/0x180 [ 197.080809] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080838] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080861] drm_ioctl_kernel+0x154/0x1a0 [drm] [ 197.080885] drm_ioctl+0x624/0x8f0 [drm] [ 197.080910] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080934] ? drm_getunique+0x210/0x210 [drm] [ 197.080943] ? __handle_mm_fault+0x1bd0/0x1ce0 [ 197.080949] ? lock_downgrade+0x610/0x610 [ 197.080957] ? __lru_cache_add+0x15a/0x180 [ 197.080967] do_vfs_ioctl+0xd92/0xe40 [ 197.080975] ? ioctl_preallocate+0x1b0/0x1b0 [ 197.080982] ? selinux_capable+0x20/0x20 [ 197.080991] ? __do_page_fault+0x7b7/0x9a0 [ 197.080997] ? lock_downgrade+0x5bb/0x610 [ 197.081007] ? security_file_ioctl+0x57/0x90 [ 197.081016] SyS_ioctl+0x4e/0x80 [ 197.081024] entry_SYSCALL_64_fastpath+0x18/0xad [ 197.081030] RIP: 0033:0x7f61f287a987 [ 197.081035] RSP: 002b:00007fff7d44d188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 197.081043] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f61f287a987 [ 197.081048] RDX: 00007fff7d44d1c0 RSI: 00000000c01864ba RDI: 0000000000000003 [ 197.081053] RBP: 00007f61f2b3eb00 R08: 0000000000000059 R09: 0000000000000000 [ 197.081058] R10: 0000002ea5c4a290 R11: 0000000000000246 R12: 00007f61f2b3eb58 [ 197.081063] R13: 0000000000001010 R14: 00007f61f2b3eb58 R15: 0000000000002702 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: Martin Peres <martin.peres@linux.intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Kiran S Kumar <kiran.s.kumar@intel.com> Cc: Kausal Malladi <kausalmalladi@gmail.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20170724091431.24251-1-maarten.lankhorst@linux.intel.com Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (cherry picked from commit 09a92bc8773b4314e02b478e003fe5936ce85adb) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-16drm/etnaviv: Fix off-by-one error in reloc checkingWladimir J. van der Laan1-2/+2
commit d6f756e09f01ea7a0efbbcef269a1e384a35d824 upstream. A relocation pointing to the last four bytes of a buffer can legitimately happen in the case of small vertex buffers. Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-16drm/bridge: tc358767: fix probe without attached output nodeLucas Stach1-1/+1
commit d630213f2a47933e1037909273a20023ba3e598d upstream. The output node of the TC358767 is only used if another bridge is chained behind it. Panels attached to the TC358767 can be detected using the usual DP AUX probing. This restores the old behavior of ignoring the output if no endpoint is found. Fixes: ebc944613567 (drm: convert drivers to use drm_of_find_panel_or_bridge) Acked-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20170710124125.9019-1-l.stach@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-11drm/vmwgfx: Fix cursor hotspot issue with Wayland on FedoraSinclair Yeh1-0/+9
commit 14979adb0294f04cf6fbbb81555acff9ec1e7c9c upstream. Parts of commit <8fbf9d92a7bc> (“drm/vmwgfx: Implement the cursor_set2 callback v2”) were not moved over when we started atomic mode set development because at that time the DRM did not support cursor hotspots in the fb struct. This patch fixes what was not moved over. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Tested-by: Brian Paul <brianp@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-11drm/amdgpu: Fix undue fallthroughs in golden registers initializationJean Delvare1-0/+2
commit 5694785cf09bf0e7bd8e5f62361ea34fa162a4a0 upstream. As I was staring at the si_init_golden_registers code, I noticed that the Pitcairn initialization silently falls through the Cape Verde initialization, and the Oland initialization falls through the Hainan initialization. However there is no comment stating that this is intentional, and the radeon driver doesn't have any such fallthrough, so I suspect this is not supposed to happen. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") Cc: Ken Wang <Qingqing.Wang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Marek Olšák" <maraeo@gmail.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-11drm/amdgpu: fix header on gfx9 clear stateAlex Deucher1-20/+21
commit c471e70b187e62efc77bcdf6f58795907f8f4851 upstream. This got missed when we open sourced this. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-06drm/i915: Fix scaler init during CRTC HW state readoutImre Deak1-7/+7
commit 283d6860d64f5091565bf729b0a6d6af14ae6c27 upstream. The scaler allocation code depends on a non-zero default value for the crtc scaler_id, so make sure we initialize the scaler state accordingly even if the crtc is off. This fixes at least an initial YUV420 modeset (added in a follow-up patchset by Shashank) when booting with the screen off: after the initial HW readout and modeset which enables the scaler a subsequent modeset will disable the scaler which isn't properly allocated. This results in a funky HW state where the pipe scaler HW registers can't be modified and the normally black screen is grey and shifted to the right or jitters. The problem was revealed by Shashank's YUV420 patchset and first reported by Ville. v2: - In the stable tag also include versions which need backporting (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 5fb9dadf336f3590c799e8cbde348215dccc2aa2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-06drm/nouveau/bar/gf100: fix access to upper half of BAR2Ben Skeggs1-1/+1
commit 38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream. Bit 30 being set causes the upper half of BAR2 to stay in physical mode, mapped over the end of VRAM, even when the rest of the BAR has been set to virtual mode. We inherited our initial value from RM, but I'm not aware of any reason we need to keep it that way. This fixes severe GPU hang/lockup issues revealed by Wayland on F26. Shout-out to NVIDIA for the quick response with the potential cause! Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-06drm/nouveau/disp/nv50-: bump max chans to 21Ilia Mirkin1-1/+1
commit a90e049cacd965dade4dae7263b4d3fd550e78b6 upstream. GP102's cursors go from chan 17..20. Increase the array size to hold their data properly. Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices") Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-06drm/vmwgfx: Limit max desktop dimensions to 8Kx8KSinclair Yeh1-2/+2
commit 7b009e76797c82178d7a03ae0eaad5951d975277 upstream. This was originally chosen to be an arbitrarily large number. However, some user mode may actually try to set a 16Kx16K mode and run into other issues. Since 8Kx8K is the current texture limit for Mesa LLVM driver, we will just use this limit for now. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-06drm/vmwgfx: Fix gcc-7.1.1 warningSinclair Yeh1-1/+1
commit fcfffdd8f98ac305285dca568b5065ef86be6458 upstream. The current code does not look correct, and the reason for it is probably lost. Since this now generates a compiler warning, fix it to what makes sense. Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/i915: reintroduce VLV/CHV PFI programming power domain workaroundGabriel Krisman Bertazi1-0/+20
commit 9c75b185274b7766fe69c2e73607c1ed780b284b upstream. There are still cases on these platforms where an attempt is made to configure the CDCLK while the power domain is off, like when coming back from a suspend. So the workaround below is still needed. This effectively reverts commit 63ff30442519 ("drm/i915: Nuke the VLV/CHV PFI programming power domain workaround"). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101517 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170628210605.4994-1-krisman@collabora.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 886015a0ad43c7fc034b23ea4614ba39162f9ddd) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/i915: Hold RPM wakelock while initializing OA buffersagar.a.kamble@intel.com1-6/+6
commit 04941829b0049d2446c7042ab9686dd057d809a6 upstream. OA buffer initialization involves access to HW registers to set the OA base, head and tail. Ensure device is awake while setting these. With this, all oa.ops are covered under RPM and forcewake wakelock. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498585181-23048-1-git-send-email-sagar.a.kamble@intel.com Fixes: d79651522e89c ("drm/i915: Enable i915 perf stream for Haswell OA unit") (cherry picked from commit 987f8c444aa2c33d98e7030d0c5f0a5325cc84ea) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/i915/fbdev: Check for existence of ifbdev->vma before operationsChris Wilson1-5/+6
commit 7581d5ca2bb269cfc2ce2d0cb489aac513167f6b upstream. Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer flushes") adds a dependency to ifbdev->vma when flushing the framebufer, but the checks are only against the existence of the ifbdev->fb and not against ifbdev->vma. This leaves a window of opportunity where we may try to operate on the fbdev prior to it being probed (thanks to asynchronous booting). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101534 Fixes: fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer flushes") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170622160211.783-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (cherry picked from commit 15727ed0d944ce1dec8b9e1082dd3df29a0fdf44) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/imx: parallel-display: Accept drm_of_find_panel_or_bridge failurePhilipp Zabel1-1/+1
commit 799ee2970485dc206c3bf347d6e6827c04d5e4f9 upstream. The parallel panel driver should continue to work without having an endpoint linking to an panel in DT for backwards compatibility. With the recent switch to drm_of_find_panel_or_bridge, an absent panel results in a failure with -ENODEV error return code. To restore the old behaviour, ignore the -ENODEV return code. Reported-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Fixes: ebc944613567 ("drm: convert drivers to use drm_of_find_panel_or_bridge") Tested-by: Chris Healy <cphealy@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/i915: Make DP-MST connector info workMaarten Lankhorst1-1/+1
commit 50740024bc393b608f7e391ac35e70f33938dd24 upstream. Commit 9a148a96fc3a ("drm/i915/debugfs: add dp mst info") adds support for DP-MST to intel_connector_info, but forgot to remove the early return for DP-MST. Remove it, and print out MST connectors directly. Fixes: 9a148a96fc3a ("drm/i915/debugfs: add dp mst info") Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Libin Yang <libin.yang@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170626083349.24389-1-maarten.lankhorst@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> (cherry picked from commit 77d1f615c78a73a04254fa2bff07ee9fa27145d9) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/mst: Avoid processing partially received up/down message transactionsImre Deak1-7/+24
commit 636c4c3e762b62aa93632c645ca65879285b16e3 upstream. Currently we may process up/down message transactions containing uninitialized data. This can happen if there was an error during the reception of any message in the transaction, but we happened to receive the last message correctly with the end-of-message flag set. To avoid this abort the reception of the transaction when the first error is detected, rejecting any messages until a message with the start-of-message flag is received (which will start a new transaction). This is also what the DP 1.4 spec 2.11.8.2 calls for in this case. In addtion this also prevents receiving bogus transactions without the first message with the the start-of-message flag set. v2: - unchanged v3: - git add the part that actually skips messages after an error in drm_dp_sideband_msg_build() Cc: Dave Airlie <airlied@redhat.com> Cc: Lyude <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719134632.13366-1-imre.deak@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()Imre Deak1-1/+3
commit 7f8b3987da54cb4d41ad2545cd4d7958b9a36bdf upstream. In case of an unknown broadcast message is sent mstb will remain unset, so check for this. Cc: Dave Airlie <airlied@redhat.com> Cc: Lyude <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-3-imre.deak@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/mst: Fix error handling during MST sideband message receptionImre Deak1-2/+8
commit 448421b5e93b9177c5698f0cf6f5e72d2995eeca upstream. Handle any error due to partial reads, timeouts etc. to avoid parsing uninitialized data subsequently. Also bail out if the parsing itself fails. Cc: Dave Airlie <airlied@redhat.com> Cc: Lyude <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-2-imre.deak@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fbMaarten Lankhorst1-0/+1
commit 4086d90cffb8f48400d51fbab575fe50458512e3 upstream. All atomic state should be cleared when drm_modeset_backoff() is called, because it drops all locks and the state becomes invalid. The call to drm_atomic_state_clear was missing in atomic_remove_fb, so add the missing call there. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170629115954.26029-1-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: db8f6403e88a ("drm: Convert drm_framebuffer_remove to atomic, v4.") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/i915/gvt: Fix inconsistent locks holding sequenceChuanxiao Dong1-5/+9
commit f16bd3dda2c8bf6699e808cd9cc540cfab10e60e upstream. There are two kinds of locking sequence. One is in the thread which is started by vfio ioctl to do the iommu unmapping. The locking sequence is: down_read(&group_lock) ----> mutex_lock(&cached_lock) The other is in the vfio release thread which will unpin all the cached pages. The lock sequence is: mutex_lock(&cached_lock) ---> down_read(&group_lock) And, the cache_lock is used to protect the rb tree of the cache node and doing vfio unpin doesn't require this lock. Move the vfio unpin out of the cache_lock protected region. v2: - use for style instead of do{}while(1). (Zhenyu) Fixes: f30437c5e7bf ("drm/i915/gvt: add KVMGT support") Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/i915: Disable MSI for all pre-gen5Ville Syrjälä1-3/+5
commit ce3f7163e4ce8fd583dcb36b6ee6b81fd1b419ae upstream. We have pretty clear evidence that MSIs are getting lost on g4x and somehow the interrupt logic doesn't seem to recover from that state even if we try hard to clear the IIR. Disabling IER around the normal IIR clearing in the irq handler isn't sufficient to avoid this, so the problem really seems to be further up the interrupt chain. This should guarantee that there's always an edge if any IIR bits are set after the interrupt handler is done, which should normally guarantee that the CPU interrupt is generated. That approach seems to work perfectly on VLV/CHV, but apparently not on g4x. MSI is documented to be broken on 965gm at least. The chipset spec says MSI is defeatured because interrupts can be delayed or lost, which fits well with what we're seeing on g4x. Previously we've already disabled GMBUS interrupts on g4x because somehow GMBUS manages to raise legacy interrupts even when MSI is enabled. Since there's such widespread MSI breakahge all over in the pre-gen5 land let's just give up on MSI on these platforms. Seqno reporting might be negatively affected by this since the legcy interrupts aren't guaranteed to be ordered with the seqno writes, whereas MSI interrupts may be? But an occasioanlly missed seqno seems like a small price to pay for generally working interrupts. Cc: Diego Viola <diego.viola@gmail.com> Tested-by: Diego Viola <diego.viola@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit e38c2da01f76cca82b59ca612529b81df82a7cc7) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/amd/powerplay: fix memory leak in cz_hwmgr backendHawking Zhang1-0/+6
commit b1e8b9c5b19c58e3159c2acc77167f4a4c74621f upstream. vddc_dep_on_dal_pwrl is allocated and initialized in cz_hwmgr_backend_init Thus free the memory in cz_hwmgr_backend_fini Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/etnaviv: Expose our reservation object when exporting a dmabuf.Eric Anholt3-0/+9
commit 8555137e26618490cbeb12c243818539875d12f4 upstream. Without this, polling on the dma-buf (and presumably other devices synchronizing against our rendering) would return immediately, even while the BO was busy. Signed-off-by: Eric Anholt <eric@anholt.net> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/ttm: Fix use-after-free in ttm_bo_clean_mmJohn Brooks1-1/+3
commit 8046e1955465e3f24e9154d0f2a2e0a8e3f8dccf upstream. We unref the man->move fence in ttm_bo_clean_mm() and then call ttm_bo_force_list_clean() which waits on it, except the refcount is now zero so a warning is generated (or worse): [149492.279301] refcount_t: increment on 0; use-after-free. [149492.279309] ------------[ cut here ]------------ [149492.279315] WARNING: CPU: 3 PID: 18726 at lib/refcount.c:150 refcount_inc+0x2b/0x30 [149492.279315] Modules linked in: vhost_net vhost tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu( -) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm [149492.279326] CPU: 3 PID: 18726 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1 [149492.279326] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014 [149492.279327] task: ffff8804ddfedcc0 task.stack: ffffc90008d20000 [149492.279329] RIP: 0010:refcount_inc+0x2b/0x30 [149492.279330] RSP: 0018:ffffc90008d23c30 EFLAGS: 00010286 [149492.279331] RAX: 000000000000002b RBX: 0000000000000170 RCX: 0000000000000000 [149492.279331] RDX: 0000000000000000 RSI: ffff88051ecccbe8 RDI: ffff88051ecccbe8 [149492.279332] RBP: ffffc90008d23c30 R08: 0000000000000001 R09: 00000000000003ee [149492.279333] R10: ffffc90008d23bb0 R11: 00000000000003ee R12: ffff88043aaac960 [149492.279333] R13: ffff8805005e28a8 R14: 0000000000000002 R15: ffff88050115e178 [149492.279334] FS: 00007fc540168700(0000) GS:ffff88051ecc0000(0000) knlGS:0000000000000000 [149492.279335] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [149492.279336] CR2: 00007fc3e8654140 CR3: 000000027ba77000 CR4: 00000000001426e0 [149492.279337] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [149492.279337] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [149492.279338] Call Trace: [149492.279345] ttm_bo_force_list_clean+0xb9/0x110 [ttm] [149492.279348] ttm_bo_clean_mm+0x7a/0xe0 [ttm] [149492.279375] amdgpu_ttm_fini+0xc9/0x1f0 [amdgpu] [149492.279392] amdgpu_bo_fini+0x12/0x40 [amdgpu] [149492.279415] gmc_v7_0_sw_fini+0x32/0x40 [amdgpu] [149492.279430] amdgpu_fini+0x2c9/0x490 [amdgpu] [149492.279445] amdgpu_device_fini+0x58/0x1b0 [amdgpu] [149492.279461] amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu] [149492.279470] drm_dev_unregister+0x3c/0xe0 [drm] [149492.279485] amdgpu_pci_remove+0x19/0x30 [amdgpu] [149492.279487] pci_device_remove+0x39/0xc0 [149492.279490] device_release_driver_internal+0x155/0x210 [149492.279491] driver_detach+0x38/0x70 [149492.279493] bus_remove_driver+0x4c/0xa0 [149492.279494] driver_unregister+0x2c/0x40 [149492.279496] pci_unregister_driver+0x21/0x90 [149492.279520] amdgpu_exit+0x15/0x406 [amdgpu] [149492.279523] SyS_delete_module+0x1a8/0x270 [149492.279525] ? exit_to_usermode_loop+0x92/0xa0 [149492.279528] entry_SYSCALL_64_fastpath+0x13/0x94 [149492.279529] RIP: 0033:0x7fc53fcb68e7 [149492.279529] RSP: 002b:00007ffcfbfaabb8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [149492.279531] RAX: ffffffffffffffda RBX: 0000563117adb200 RCX: 00007fc53fcb68e7 [149492.279531] RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000563117adb268 [149492.279532] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999 [149492.279533] R10: 0000000000000883 R11: 0000000000000206 R12: 00007ffcfbfa9ba0 [149492.279533] R13: 0000000000000000 R14: 0000000000000000 R15: 0000563117adb200 [149492.279534] Code: 55 48 89 e5 e8 77 fe ff ff 84 c0 74 02 5d c3 80 3d 40 f2 a4 00 00 75 f5 48 c7 c7 20 3c ca 81 c6 05 30 f2 a4 00 01 e8 91 f0 d7 ff <0f> ff 5d c3 90 55 48 89 fe bf 01 00 00 00 48 89 e5 e8 9f fe ff [149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]--- Unref the fence *after* waiting for it. v2: Set man->move to NULL after dropping the last ref (Christian König) Fixes: aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean) Signed-off-by: John Brooks <john@fastquake.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/radeon: Fix eDP for single-display iMac10,1 (v2)Mario Kleiner1-2/+11
commit 564d8a2cf3abf16575af48bdc3e86e92ee8a617d upstream. The late 2009, 27 inch Apple iMac10,1 has an internal eDP display and an external Mini- Displayport output, driven by a DCE-3.2, RV730 Radeon Mobility HD-4670. The machine worked fine in a dual-display setup with eDP panel + externally connected HDMI or DVI-D digital display sink, connected via MiniDP to DVI or HDMI adapter. However, booting the machine single-display with only eDP panel results in a completely black display - even backlight powering off, as soon as the radeon modesetting driver loads. This patch fixes the single dispay eDP case by assigning encoders based on dig->linkb, similar to DCE-4+. While this should not be generally necessary (Alex: "...atom on normal boards should be able to handle any mapping."), Apple seems to use some special routing here. One remaining problem not solved by this patch is that an external Minidisplayport->DP sink does still not work on iMac10,1, whereas external DVI and HDMI sinks continue to work. The problem affects at least all tested kernels since Linux 3.13 - didn't test earlier kernels, so backporting to stable probably makes sense. v2: With the original patch from 2016, Alex was worried it will break other DCE3.2 systems. Use dmi_match() to apply this special encoder assignment only for the Apple iMac 10,1 from late 2009. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/radeon/ci: disable mclk switching for high refresh rates (v2)Alex Deucher1-0/+6
commit ab03d9fe508f4e2914a8f4a9eef1b21051cacd0f upstream. Even if the vblank period would allow it, it still seems to be problematic on some cards. v2: fix logic inversion (Nils) bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868 Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/amdgpu: Don't call amd_powerplay_destroy() if we don't have powerplayJohn Brooks1-1/+2
commit 7bc7b7777ee0e3b3d995aebaf26a462d5a23e3d7 upstream. amd_powerplay_destroy() expects a handle pointing to a struct pp_instance. On chips without PowerPlay, pp_handle points to a struct amdgpu_device. The resulting attempt to kfree() fields of the wrong struct ends in fire: [ 91.560405] BUG: unable to handle kernel paging request at ffffebe000000620 [ 91.560414] IP: kfree+0x57/0x160 [ 91.560416] PGD 0 [ 91.560416] P4D 0 [ 91.560420] Oops: 0000 [#1] SMP [ 91.560422] Modules linked in: tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm [ 91.560438] CPU: 6 PID: 3598 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1 [ 91.560443] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014 [ 91.560448] task: ffff8805063d6a00 task.stack: ffffc90003400000 [ 91.560451] RIP: 0010:kfree+0x57/0x160 [ 91.560454] RSP: 0018:ffffc90003403cc0 EFLAGS: 00010286 [ 91.560457] RAX: 000077ff80000000 RBX: 00000000000186a0 RCX: 0000000180400035 [ 91.560460] RDX: 0000000180400036 RSI: ffffea001418e740 RDI: ffffea0000000000 [ 91.560463] RBP: ffffc90003403cd8 R08: 000000000639d201 R09: 0000000180400035 [ 91.560467] R10: ffffebe000000600 R11: 0000000000000300 R12: ffff880500530030 [ 91.560470] R13: ffffffffa01e70fc R14: 00000000ffffffff R15: ffff880500530000 [ 91.560473] FS: 00007f7e500c3700(0000) GS:ffff88051ed80000(0000) knlGS:0000000000000000 [ 91.560478] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 91.560480] CR2: ffffebe000000620 CR3: 0000000503103000 CR4: 00000000001406e0 [ 91.560483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 91.560487] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 91.560489] Call Trace: [ 91.560530] amd_powerplay_destroy+0x1c/0x60 [amdgpu] [ 91.560558] amdgpu_pp_late_fini+0x44/0x60 [amdgpu] [ 91.560575] amdgpu_fini+0x254/0x490 [amdgpu] [ 91.560593] amdgpu_device_fini+0x58/0x1b0 [amdgpu] [ 91.560610] amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu] [ 91.560622] drm_dev_unregister+0x3c/0xe0 [drm] [ 91.560638] amdgpu_pci_remove+0x19/0x30 [amdgpu] [ 91.560643] pci_device_remove+0x39/0xc0 [ 91.560648] device_release_driver_internal+0x155/0x210 [ 91.560651] driver_detach+0x38/0x70 [ 91.560655] bus_remove_driver+0x4c/0xa0 [ 91.560658] driver_unregister+0x2c/0x40 [ 91.560662] pci_unregister_driver+0x21/0x90 [ 91.560689] amdgpu_exit+0x15/0x406 [amdgpu] [ 91.560694] SyS_delete_module+0x1a8/0x270 [ 91.560698] ? exit_to_usermode_loop+0x92/0xa0 [ 91.560702] entry_SYSCALL_64_fastpath+0x13/0x94 [ 91.560705] RIP: 0033:0x7f7e4fc118e7 [ 91.560708] RSP: 002b:00007fff978ca118 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 91.560713] RAX: ffffffffffffffda RBX: 000055afe21bc200 RCX: 00007f7e4fc118e7 [ 91.560716] RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055afe21bc268 [ 91.560719] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999 [ 91.560722] R10: 0000000000000883 R11: 0000000000000206 R12: 00007fff978c9100 [ 91.560725] R13: 0000000000000000 R14: 0000000000000000 R15: 000055afe21bc200 [ 91.560728] Code: 00 00 00 80 ff 77 00 00 48 bf 00 00 00 00 00 ea ff ff 49 01 da 48 0f 42 05 57 33 bd 00 49 01 c2 49 c1 ea 0c 49 c1 e2 06 49 01 fa <49> 8b 42 20 48 8d 78 ff a8 01 4c 0f 45 d7 49 8b 52 20 48 8d 42 [ 91.560759] RIP: kfree+0x57/0x160 RSP: ffffc90003403cc0 [ 91.560761] CR2: ffffebe000000620 [ 91.560765] ---[ end trace 08a9f3cd82223c1d ]--- Fixes: 1c8638024846 (drm/amd/powerplay: refine powerplay interface.) Signed-off-by: John Brooks <john@fastquake.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/amdgpu: fix the memory corruption on S3Huang Rui1-8/+7
commit 67bef0f7908a3a6b10e5a29d8e8c09e27f90c9f8 upstream. psp->cmd will be used on resume phase, so we can not free it on hw_init. Otherwise, a memory corruption will be triggered. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Tested-by: Xiaojie Yuan <Xiaojie.Yuan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/amd/amdgpu: Return error if initiating read out of range on vramTom St Denis1-0/+3
commit 9156e723301c0a7a7def4cde820e018ce791b842 upstream. If you initiate a read that is out of the VRAM address space return ENXIO instead of 0. Reads that begin below that point will read upto the VRAM limit as before. Signed-off-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/amdgpu/cgs: always set reference clock in mode_infoAlex Deucher1-1/+4
commit 73cc90798ff765341a1d9c2cfe18153ab231c9bb upstream. It's relevent regardless of whether there are displays enabled. Fixes garbage values for ref clock in powerplay leading to incorrect fan speed reporting when displays are disabled. bug: https://bugs.freedesktop.org/show_bug.cgi?id=101653 Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/amdgpu: fix vblank_time when displays are offAlex Deucher1-0/+3
commit beb3777682d5c296cc15a2a424f5a7a98476def0 upstream. If the displays are off, set the vblank time to max to make sure mclk switching is enabled. Avoid mclk getting set to high when no displays are attached. bug: https://bugs.freedesktop.org/show_bug.cgi?id=101528 fixes: 09be4a5219 (drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)) Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-28drm/amdgpu/gfx8: drop per-APU CU limitsAlex Deucher1-69/+2
commit 943c05bdb53da273c43ec44eec37c6a70409b5e9 upstream. Always use the max for the family rather than the per sku limits. This makes sure the mask is always the max size to avoid reporting the wrong number of CUs. Reviewed-by: Alex Xie <AlexBin.Xie@amd.com> Reviewed-by: Andres Rodriguez <andresx7@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-21drm/amdgpu/gfx6: properly cache mc_arb_ramcfgAlex Deucher1-1/+2
commit 6653ebd48f493efe3f3598ff3fe7b3d5451665df upstream. This was missing for gfx6. Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-28Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds4-4/+25
Pull drm fixes from Dave Airlie: "This is the final set of fixes for -rc8, just a few i915 and one vmwgfx ones. I'm off on holidays for a week, so if anything shows up for fixes I've asked Daniel or Sean Paul to herd it in the right direction" [ The additional etnaviv fixes were already herded towards me as seen in my previous pull - Linus ] * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations drm/i915: Hold struct_mutex for per-file stats in debugfs/i915_gem_object drm/i915: Retire the VMA's fence tracker before unbinding
2017-06-28Merge branch 'etnaviv/fixes' of git://git.pengutronix.de/git/lst/linuxLinus Torvalds2-2/+3
Pull drm/etnaviv fixes from Lucas Stach: "I realized I just missed the cut-off point for the final drm fixes pull, but I have 2 more etnaviv fixes that need to go into 4.12, as they fix fallout from the explicit sync work introduced in the last merge window" [ Pulling directly because Dave is on vacation. Noted by Daniel Vetter, and acked by Dave Airlie - Linus ] * 'etnaviv/fixes' of git://git.pengutronix.de/git/lst/linux: drm/etnaviv: Fix implicit/explicit sync sense inversion drm/etnaviv: fix submit flags getting overwritten by BO content
2017-06-28drm/etnaviv: Fix implicit/explicit sync sense inversionDaniel Stone1-1/+1
We were reading the no-implicit sync flag the wrong way around, synchronizing too much for the explicit case, and not at all for the implicit case. Oops. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-06-28drm/etnaviv: fix submit flags getting overwritten by BO contentLucas Stach1-1/+2
The addition of the flags member to etnaviv_gem_submit structure didn't take into account that the last member of this structure is a variable length array. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-06-28Merge tag 'drm-intel-fixes-2017-06-27' of ↵Dave Airlie3-4/+24
git://anongit.freedesktop.org/git/drm-intel into drm-fixes Just a few minor fixes. Important one is the execbuf async fix (aka ANDROID_native_sync). There was another patch for a display coherency corner case on APL, but we've random-walked in that space too much, and the cherry-pick looked really invasive. * tag 'drm-intel-fixes-2017-06-27' of git://anongit.freedesktop.org/git/drm-intel: drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations drm/i915: Hold struct_mutex for per-file stats in debugfs/i915_gem_object drm/i915: Retire the VMA's fence tracker before unbinding
2017-06-28Merge branch 'vmwgfx-fixes-4.12' of ↵Dave Airlie1-0/+1
git://people.freedesktop.org/~thomash/linux into drm-fixes Single vmwgfx fix * 'vmwgfx-fixes-4.12' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr
2017-06-26drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgrDeepak Rawat1-0/+1
The hash table created during vmw_cmdbuf_res_man_create was never freed. This causes memory leak in context creation. Added the corresponding drm_ht_remove in vmw_cmdbuf_res_man_destroy. Tested for memory leak by running piglit overnight and kernel memory is not inflated which earlier was. Cc: <stable@vger.kernel.org> Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2017-06-26drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocationsChris Wilson1-3/+14
If we write a relocation into the buffer, we require our own implicit synchronisation added after the start of the execbuf, outside of the user's control. As we may end up clflushing, or doing the patch itself on the GPU, asynchronously we need to look at the implicit serialisation on obj->resv and hence need to disable EXEC_OBJECT_ASYNC for this object. If the user does trigger a stall for relocations, we make sure the stall is complete enough so that the batch is not submitted before we complete those relocations. Fixes: 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 071750e550af46b5d3a84ad56c2a108c3e136284) [danvet: Resolve conflicts, resolution reviewed by Tvrtko on irc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-06-26drm/i915: Hold struct_mutex for per-file stats in debugfs/i915_gem_objectChris Wilson1-1/+5
As we walk the obj->vma_list in per_file_stats(), we need to hold struct_mutex to prevent alteration of that list. Fixes: 1d2ac403ae3b ("drm: Protect dev->filelist with its own mutex") Fixes: c84455b4bacc ("drm/i915: Move debug only per-request pid tracking from request to ctx") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101460 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170617115744.4452-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (cherry picked from commit 0caf81b5c53d9bd332a95dbcb44db8de0b397a7c) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-06-26drm/i915: Retire the VMA's fence tracker before unbindingChris Wilson1-0/+5
Since we may track unfenced access (GPU access to the vma that explicitly requires no fence), vma->last_fence may be set without any attached fence (vma->fence) and so will not be flushed when we call i915_vma_put_fence(). Since we stopped doing a full retire of the activity trackers for unbind, we need to explicitly retire each tracker. Fixes: b0decaf75bd9 ("drm/i915: Track active vma requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> (cherry picked from commit 760a898d8069111704e1bd43f00ebf369ae46e57) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-06-23Merge tag 'drm-misc-fixes-2017-06-22' of ↵Dave Airlie1-18/+20
git://anongit.freedesktop.org/git/drm-misc into drm-fixes UAPI Changes: - drm: Fix regression in GETCONNECTOR ioctl returning stale properties (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> * tag 'drm-misc-fixes-2017-06-22' of git://anongit.freedesktop.org/git/drm-misc: drm: Fix GETCONNECTOR regression
2017-06-21drm: Fix GETCONNECTOR regressionDaniel Vetter1-18/+20
In commit 91eefc05f0ac71902906b2058360e61bd25137fe Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Dec 14 00:08:10 2016 +0100 drm: Tighten locking in drm_mode_getconnector I reordered the logic a bit in that IOCTL, but that broke userspace since it'll get the new mode list, but not the new property values. Fix that again. v2: Fix up the error path handling when copy_to_user for the modes failes (Dhinakaran). Fixes: 91eefc05f0ac ("drm: Tighten locking in drm_mode_getconnector") Cc: Sean Paul <seanpaul@chromium.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Reported-by: "H.J. Lu" <hjl.tools@gmail.com> Tested-by: "H.J. Lu" <hjl.tools@gmail.com> Cc: <stable@vger.kernel.org> # v4.11+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100576 Cc: "H.J. Lu" <hjl.tools@gmail.com> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170620202837.1701-1-daniel.vetter@ffwll.ch
2017-06-21Merge branch 'drm-fixes-4.12' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie5-2/+18
into drm-fixes A few fixes for 4.12: - Add a new Polaris12 pci id - A stack corruption fix - Suspend/resume fix - PX fix - Display flickering fix * 'drm-fixes-4.12' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: add a quirk for Toshiba Satellite L20-183 drm/radeon: add a PX quirk for another K53TK variant drm/amdgpu: adjust default display clock drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating drm/amdgpu: add Polaris12 DID
2017-06-21Merge tag 'drm-intel-fixes-2017-06-20' of ↵Dave Airlie8-60/+107
git://anongit.freedesktop.org/git/drm-intel into drm-fixes drm/i915 fixes for v4.12-rc7 * tag 'drm-intel-fixes-2017-06-20' of git://anongit.freedesktop.org/git/drm-intel: drm/i915: Don't enable backlight at setup time. drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic() drm/i915: Fix deadlock witha the pipe A quirk during resume drm/i915: Remove __GFP_NORETRY from our buffer allocator drm/i915: Encourage our shrinker more when our shmemfs allocations fails drm/i915: Differentiate between sw write location into ring and last hw read