summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2015-04-032-7/+8
|\ | | | | | | | | | | | | | | | | | | into drm-fixes Just two small fixes for radeon, both destined for stable. * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: fix wait in radeon_mn_invalidate_range_start drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr
| * drm/radeon: fix wait in radeon_mn_invalidate_range_startChristian König2015-04-021-7/+4
| | | | | | | | | | | | | | | | We need to wait for all fences, not just the exclusive one. Signed-off-by: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/radeon: add extra check in radeon_ttm_tt_unpin_userptrChristian König2015-04-021-0/+4
| | | | | | | | | | | | | | | | | | | | We somehow try to free the SG table twice. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734 Signed-off-by: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | Merge branch 'exynos-drm-fixes' of ↵Dave Airlie2015-04-032-10/+15
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Fix display on issue to Exynos5250 based Snow(1366x768) board. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm: Exynos: Respect framebuffer pitch for FIMD/Mixer
| * | drm: Exynos: Respect framebuffer pitch for FIMD/MixerDaniel Stone2015-04-022-10/+15
| |/ | | | | | | | | | | | | | | | | | | | | | | When performing a modeset, use the framebuffer pitch value to set FIMD IMG_SIZE and Mixer SPAN registers. These are both defined as pitch - the distance between contiguous lines (bytes for FIMD, pixels for mixer). Fixes display on Snow (1366x768). Signed-off-by: Daniel Stone <daniels@collabora.com> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | Merge tag 'drm-intel-fixes-2015-04-02' of ↵Dave Airlie2015-04-032-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes one oops fixes and a 0-length allocation fix from next backported. * tag 'drm-intel-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel: drm/i915: Reject the colorkey ioctls for primary and cursor planes drm/i915: Skip allocating shadow batch for 0-length batches
| * | drm/i915: Reject the colorkey ioctls for primary and cursor planesVille Syrjälä2015-04-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The legcy colorkey ioctls are only implemented for sprite planes, so reject the ioctl for primary/cursor planes. If we want to support colorkeying with these planes (assuming we have hw support of course) we should just move ahead with the colorkey property conversion. Testcase: kms_legacy_colorkey Cc: Tommi Rantala <tt.rantala@gmail.com> Cc: stable@vger.kernel.org Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.com Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915: Skip allocating shadow batch for 0-length batchesChris Wilson2015-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 17cabf571e50677d980e9ab2a43c5f11213003ae Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 14 11:20:57 2015 +0000 drm/i915: Trim the command parser allocations we may then try to allocate a zero-sized object and attempt to extract its pages. Understandably this fails. Note that the real offender seems to be commit b9ffd80ed659c559152c042e74741f4f60cac691 Author: Brad Volkin <bradley.d.volkin@intel.com> Date: Thu Dec 11 12:13:10 2014 -0800 drm/i915: Use batch length instead of object size in command parser Testcase: igt/gem_exec_nop #ivb,byt,hsw Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [cherry picked from commit 743e78c1d726d875b98ff9689cc77c4d3d5d9ae2 from drm-intel-next because 4.0 seems to be affected by this too, despite that the obvious culprit is definitely not in 4.0. Whatever, if fixes a bug. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* | | Merge tag 'topic/drm-fixes-2015-04-02' of ↵Dave Airlie2015-04-032-0/+2
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes Here's a single drm core fix, cc: stable, that affects i915 users. * tag 'topic/drm-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel: drm/edid: set ELD for firmware and debugfs override EDIDs
| * | drm/edid: set ELD for firmware and debugfs override EDIDsJani Nikula2015-03-272-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user supplies EDID through firmware or debugfs override, the driver callbacks are bypassed and the connector ELD does not get updated, and audio fails. Set ELD for firmware and debugfs EDIDs too. There should be no harm in gratuitously doing this for non HDMI/DP connectors, as it's still up to the driver to use the ELD, if any. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691 Reported-by: Emil <emilsvennesson@gmail.com> Reported-by: Rob Engle <grenoble@gmail.com> Tested-by: Jolan Luff <jolan@gormsby.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | drm/radeon: programm the VCE fw BAR as wellChristian König2015-03-272-0/+4
| | | | | | | | | | | | | | | | | | | | | Otherwise the VCE firmware needs to be in the first 256MB of VRAM. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon: always dump the ring content if it's availableChristian König2015-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Dumping is still possible if a ring isn't ready, only when it isn't allocated at all we need to abort here. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | radeon: Do not directly dereference pointers to BIOS area.David Miller2015-03-271-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Use readb() and memcpy_fromio() accessors instead. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | | drm/radeon/dpm: fix 120hz handling harderAlex Deucher2015-03-272-5/+18
| |/ |/| | | | | | | | | | | | | | | | | | | Need to expand the check to handle short circuiting if the selected state is the same as current state. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87796 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | drm/i915: Fixup legacy plane->crtc link for initial fb configDaniel Vetter2015-03-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a very similar bug in the load detect code fixed in commit 9128b040eb774e04bc23777b005ace2b66ab2a85 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Mar 3 17:31:21 2015 +0100 drm/i915: Fix modeset state confusion in the load detect code But this time around it was the initial fb code that forgot to update the plane->crtc pointer. Otherwise it's the exact same bug, with the exact same restrains (any set_config call/ioctl that doesn't disable the pipe papers over the bug for free, so fairly hard to hit in normal testing). So if you want the full explanation just go read that one over there - it's rather long ... Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: backported to drm-intel-fixes for v4.0-rc] Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Fix atomic state when reusing the firmware fbDamien Lespiau2015-03-261-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now, we get a warning when taking over the firmware fb: [drm:drm_atomic_plane_check] FB set but no CRTC with the following backtrace: [<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm] [<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper] [<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm] [<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper] [<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper] [<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] [<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915] [<ffffffff813ad444>] fbcon_init+0x4f4/0x580 That's because we update the plane state with the fb from the firmware, but we never associate the plane to that CRTC. We don't quite have the full DRM take over from HW state just yet, so fake enough of the plane atomic state to pass the checks. v2: Fix the state on which we set the CRTC in the case we're sharing the initial fb with another pipe. (Matt) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: backported to drm-intel-fixes for v4.0-rc] Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Keep ring->active_list and ring->requests_list consistentChris Wilson2015-03-261-17/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we retire requests last, we may use a later seqno and so clear the requests lists without clearing the active list, leading to confusion. Hence we should retire requests first for consistency with the early return. The order used to be important as the lifecycle for the object on the active list was determined by request->seqno. However, the requests themselves are now reference counted removing the constraint from the order of retirement. Fixes regression from commit 1b5a433a4dd967b125131da42b89b5cc0d5b1f57 Author: John Harrison <John.C.Harrison@Intel.com> Date: Mon Nov 24 18:49:42 2014 +0000 drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed ' and a WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140() WARN_ON(!list_empty(&vm->active_list)) Identified by updating WATCH_LISTS: [drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230() WARN_ON(i915_verify_lists(ring->dev)) Note that this is only a problem in evict_vm where the following happens after a retire_request has cleaned out all requests, but not all active bo: - intel_ring_idle called from i915_gpu_idle notices that no requests are outstanding and immediately returns. - i915_gem_retire_requests_ring called from i915_gem_retire_requests also immediately returns when there's no request, still leaving the bo on the active list. - evict_vm hits the WARN_ON(!list_empty(&vm->active_list)) after evicting all active objects that there's still stuff left that shouldn't be there. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Don't try to reference the fb in get_initial_plane_config()Damien Lespiau2015-03-251-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tvrtko noticed a new warning on boot: WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]() Call Trace: [<ffffffff8161f10c>] dump_stack+0x4f/0x7b [<ffffffff81052caa>] warn_slowpath_common+0xaa/0xd0 [<ffffffff81052d8a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa00d035c>] drm_framebuffer_reference+0x6c/0x80 [drm] [<ffffffffa01c0df7>] update_state_fb.isra.54+0x47/0x50 [i915] [<ffffffffa01ccd5c>] skylake_get_initial_plane_config+0x93c/0x950 [i915] [<ffffffffa01e8721>] intel_modeset_init+0x1551/0x17c0 [i915] [<ffffffffa02476e0>] i915_driver_load+0xed0/0x11e0 [i915] [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa00ca8b7>] drm_dev_register+0x77/0x110 [drm] [<ffffffffa00cda3b>] drm_get_pci_dev+0x11b/0x1f0 [drm] [<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa0145276>] i915_pci_probe+0x56/0x60 [i915] [<ffffffff813ad59c>] pci_device_probe+0x7c/0x100 [<ffffffff81466aad>] driver_probe_device+0x16d/0x380 We cannot take a reference at this point, not before intel_framebuffer_init() and the underlying drm_framebuffer_init(). Introduced in: commit 706dc7b549175e47f23e913b7f1e52874a7d0f56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb v2: Don't move update_state_fb(). It was moved around because I originally put update_state_fb() in intel_alloc_plane_obj() before finding a better place. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From drm-next: (cherry picked from commit f55548b5af87ebfc586ca75748947f1c1b1a4a52) Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm: Fixup racy refcounting in plane_force_disableDaniel Vetter2015-03-241-12/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally it was impossible to be dropping the last refcount in this function since there was always one around still from the idr. But in commit 83f45fc360c8e16a330474860ebda872d1384c8c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 6 09:10:18 2014 +0200 drm: Don't grab an fb reference for the idr we've switched to weak references, broke that assumption but forgot to fix it up. Since we still force-disable planes it's only possible to hit this when racing multiple rmfb with fbdev restoring or similar evil things. As long as userspace is nice it's impossible to hit the BUG_ON. But the BUG_ON would most likely be hit from fbdev code, which usually invovles the console_lock besides all modeset locks. So very likely we'd never get the bug reports if this was hit in the wild, hence better be safe than sorry and backport. Spotted by Matt Roper while reviewing other patches. [airlied: pull this back into 4.0 - the oops happens there] Cc: stable@vger.kernel.org Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge tag 'drm-intel-fixes-2015-03-19' of ↵Dave Airlie2015-03-201-4/+28
|\ | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes Backporting a couple of plane related fixes from drm-next to v4.0. * tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel: drm/i915: Make sure the primary plane is enabled before reading out the fb state drm/i915: Ensure plane->state->fb stays in sync with plane->fb
| * drm/i915: Make sure the primary plane is enabled before reading out the fb stateDamien Lespiau2015-03-181-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't want to end up in a state where we track that the pipe has its primary plane enabled when primary plane registers are programmed with values that look possible but the plane actually disabled. Refuse to read out the fb state when the primary plane isn't enabled. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Reported-by: Steven Rostedt <rostedt@goodmis.org> Reference: http://mid.gmane.org/20150203191507.GA2374@crion86 Tested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Ensure plane->state->fb stays in sync with plane->fbXi Ruoyao2015-03-161-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | plane->state->fb and plane->fb should always reference the same FB so that atomic and legacy codepaths have the same view of display state. However, there are some places in kernel code that directly set plane->fb and neglect to update plane->state->fb. If we never do a successful update through the atomic pipeline, the RmFB cleanup code will look at the plane->state->fb pointer, which has never actually been set to a legitimate value, and try to clean it up, leading to BUG's. Add a quick helper function to synchronize plane->state->fb with plane->fb and call it everywhere the driver tries to manually set plane->fb outside of the atomic pipeline. In this function, use drm_atomic_set_fb_for_plane instead of writing plane->state->fb directly to keep the reference count right. This is modified from Matt Roper's patch to drm-intel-nightly with commit id commit afd65eb4cc0578a9c07d621acdb8a570e2782bf7 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb However this bug exists in mainline kernel too, so I created this to fix it in mainline kernel. A minor change is to use drm_atomic_set_fb_for_plane instead of update reference count manually. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93711 Signed-off-by: Xi Ruoyao <xry111@outlook.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [Jani: included the patch notes in the commit message] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | Merge tag 'drm-amdkfd-fixes-2015-03-19' of ↵Dave Airlie2015-03-203-11/+23
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~gabbayo/linux into drm-fixes - Fixing SDMA initialization when in non-HWS mode (debug mode) - Memory leak fix when destroying kernel queue - Fix number of available compute pipelines according to new firmware * tag 'drm-amdkfd-fixes-2015-03-19' of git://people.freedesktop.org/~gabbayo/linux: drm/radeon: Changing number of compute pipe lines drm/amdkfd: Fix SDMA queue init. in non-HWS mode drm/amdkfd: destroy mqd when destroying kernel queue
| * | drm/radeon: Changing number of compute pipe linesBen Goz2015-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current CP firmware can handle Usermode Queues only on MEC1. To reflect this firmware change, this commit reduces number of compute pipelines to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd). Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Cc: stable@vger.kernel.org
| * | drm/amdkfd: Fix SDMA queue init. in non-HWS modeBen Goz2015-03-161-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the SDMA queue initialization, when running in non-HWS mode. The first fix is to move the initialization of SDMA VM parameters before the initialization of the SDMA MQD. The second fix is to load the MQD to an HQD after the initialization of the MQD. Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
| * | drm/amdkfd: destroy mqd when destroying kernel queueBen Goz2015-03-161-9/+13
| |/ | | | | | | | | | | | | | | | | | | | | This patch adds a missing destruction of mqd, when destroying a kernel queue. Without the destruction, there is a memory leakage when repeatedly creating and destroying kernel queues. Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2015-03-191-11/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes single radeon fix. * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: drop ttm two ended allocation
| * | drm/radeon: drop ttm two ended allocationAlex Deucher2015-03-181-11/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | radeon_bo_create() calls radeon_ttm_placement_from_domain() before ttm_bo_init() is called. radeon_ttm_placement_from_domain() uses the ttm bo size to determine when to select top down allocation but since the ttm bo is not initialized yet the check is always false. It only took effect when buffers were validated later. It also seemed to regress suspend and resume on some systems possibly due to it not taking effect in radeon_bo_create(). radeon_bo_create() and radeon_ttm_placement_from_domain() need to be reworked substantially for this to be optimally effective. Re-enable it at that point. Noticed-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | Merge branch 'exynos-drm-fixes' of ↵Dave Airlie2015-03-196-287/+15
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Some urgent regression fixes to booting failures Exynos DRM occured. Summary: - Fix two urgent null pointer dereference bugs in case of enabling or disabling IOMMU. There was two cases to these issues. One is that plane->crtc is accessed by exynos_disable_plane() when device tree binding is broken so device driver tries to release, which means that the mode set operation isn't invoked yet so plane->crtc is still NULL and exynos_disable_plane() will access NULL pointer. This issue is fixed by checking if the plane->crtc is NULL or not in exynos_disable_plane() Other is that fimd_wait_for_vblank() is called to avoid from page fault with IOMMU before the ctx object is created. At this time, fimd_wait_for_vblank() tries to access ctx->crtc but the ctx->crtc is still NULL because exynos_drm_crtc_create() isn't called yet. This issue is fixed by creating a crtc object and setting it to ctx->crtc prior to fimd_wait_for_vblank() call. For more details, you can refer to below an e-mail thread, http://www.spinics.net/lists/linux-samsung-soc/msg42436.html - Remove unnecessary file not used and fix trivial issues. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: fix the initialization order in FIMD drm/exynos: fix typo config name correctly. drm/exynos: Check for NULL dereference of crtc drm/exynos: IS_ERR() vs NULL bug drm/exynos: remove unused files
| * | drm/exynos: fix the initialization order in FIMDHyungwon Hwang2015-03-181-18/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 0f04cf8df0b20a97369cb634663fef0578cbf273 ("drm/exynos: fix wrong pipe calculation for crtc"), fimd_clear_channel() can be called when is_drm_iommu_supported() returns true. In this case, the kernel is going to be panicked because crtc is not set yet. [ 1.211156] [drm] Initialized drm 1.1.0 20060810 [ 1.216785] Unable to handle kernel NULL pointer dereference at virtual address 00000350 [ 1.223415] pgd = c0004000 [ 1.226086] [00000350] *pgd=00000000 [ 1.229649] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1.234940] Modules linked in: [ 1.237982] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1-00062-g7a7cc79-dirty #123 [ 1.246136] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 1.252214] task: ee8c8000 ti: ee8d0000 task.ti: ee8d0000 [ 1.257606] PC is at fimd_wait_for_vblank+0x8/0xc8 [ 1.262370] LR is at fimd_bind+0x138/0x1a8 [ 1.266450] pc : [<c02fb63c>] lr : [<c02fb834>] psr: 20000113 [ 1.266450] sp : ee8d1d28 ip : 00000000 fp : 00000000 [ 1.277906] r10: 00000001 r9 : c09d693c r8 : c0a2d6a8 [ 1.283114] r7 : 00000034 r6 : 00000001 r5 : ee0bb400 r4 : ee244c10 [ 1.289624] r3 : 00000000 r2 : 00000000 r1 : 00000001 r0 : 00000000 [ 1.296135] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 1.303426] Control: 10c5387d Table: 4000404a DAC: 00000015 [ 1.309154] Process swapper/0 (pid: 1, stack limit = 0xee8d0210) [ 1.315143] Stack: (0xee8d1d28 to 0xee8d2000) [ 1.319486] 1d20: 00000000 c0113d18 ee0bb400 ee0bb400 ee245c30 eebbe210 [ 1.327645] 1d40: ee008a40 ee244c10 ee0bb400 00000001 00000034 c02fb834 00000000 c030a858 [ 1.335804] 1d60: ee244a10 eeb60780 ee008a40 eeb60740 ee0bb400 c03030d0 00000000 00000000 [ 1.343963] 1d80: ee244a10 ee0bb400 00000000 eeb60740 eeb60810 00000000 00000000 c02f6ba4 [ 1.352123] 1da0: ee0bb400 00000000 00000000 c02e0500 ee244a00 c0a04a14 ee0bb400 c02e1de4 [ 1.360282] 1dc0: 00000000 c030a858 00000002 eeb60820 eeb60820 00000002 eeb60780 c03033d4 [ 1.368441] 1de0: c06e9cec 00000000 ee244a10 eeb60780 c0a056f8 c03035fc c0a04b24 c0a04b24 [ 1.376600] 1e00: ee244a10 00000001 c0a049d0 c02f6d34 c0ad462c eeba0790 00000000 ee244a10 [ 1.384759] 1e20: ffffffed c0a049d0 00000000 c03090b0 ee244a10 c0ad462c c0a2d840 c03077a0 [ 1.392919] 1e40: eeb5e880 c024b738 000008db ee244a10 c0a049d0 ee244a44 00000000 c09e71d8 [ 1.401078] 1e60: 000000c6 c0307a6c c0a049d0 00000000 c03079e0 c0305ea8 ee826e5c ee1dc7b4 [ 1.409237] 1e80: c0a049d0 eeb5e880 c0a058a8 c0306e2c c0896204 c0a049d0 c06e9d10 c0a049d0 [ 1.417396] 1ea0: c06e9d10 c0ad4600 00000000 c0308360 00000000 00000003 c06e9d10 c02f6e14 [ 1.425555] 1ec0: 00000000 c0896204 ffffffff 00000000 00000000 00000000 00000000 00000000 [ 1.433714] 1ee0: 00000000 00000000 c02f6d5c c02f6d5c 00000000 eeb5d740 c09e71d8 c0008a30 [ 1.441874] 1f00: ef7fca5e 00000000 00000000 00000066 00000000 ee8d1f28 c003ff1c c02514e8 [ 1.450033] 1f20: 60000113 ffffffff c093906c ef7fca5e 000000c6 c004018c 00000000 c093906c [ 1.458192] 1f40: c08a9690 c093840c 00000006 00000006 c09eb2ac c09c0d74 00000006 c09c0d54 [ 1.466351] 1f60: c0a3d680 c09745a0 c09d693c 000000c6 00000000 c0974db4 00000006 00000006 [ 1.474510] 1f80: c09745a0 ffffffff 00000000 c0692e00 00000000 00000000 00000000 00000000 [ 1.482669] 1fa0: 00000000 c0692e08 00000000 c000f040 00000000 00000000 00000000 00000000 [ 1.490828] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.498988] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [ 1.507159] [<c02fb63c>] (fimd_wait_for_vblank) from [<c02fb834>] (fimd_bind+0x138/0x1a8) [ 1.515313] [<c02fb834>] (fimd_bind) from [<c03030d0>] (component_bind_all+0xc4/0x20c) [ 1.523209] [<c03030d0>] (component_bind_all) from [<c02f6ba4>] (exynos_drm_load+0xa0/0x140) [ 1.531632] [<c02f6ba4>] (exynos_drm_load) from [<c02e0500>] (drm_dev_register+0xa0/0xf4) [ 1.539788] [<c02e0500>] (drm_dev_register) from [<c02e1de4>] (drm_platform_init+0x44/0xcc) [ 1.548121] [<c02e1de4>] (drm_platform_init) from [<c03033d4>] (try_to_bring_up_master.part.1+0xc8/0x104) [ 1.557668] [<c03033d4>] (try_to_bring_up_master.part.1) from [<c03035fc>] (component_master_add_with_match+0xd0/0x118) [ 1.568431] [<c03035fc>] (component_master_add_with_match) from [<c02f6d34>] (exynos_drm_platform_probe+0xf0/0x118) [ 1.578847] [<c02f6d34>] (exynos_drm_platform_probe) from [<c03090b0>] (platform_drv_probe+0x48/0x98) [ 1.588052] [<c03090b0>] (platform_drv_probe) from [<c03077a0>] (driver_probe_device+0x140/0x380) [ 1.596902] [<c03077a0>] (driver_probe_device) from [<c0307a6c>] (__driver_attach+0x8c/0x90) [ 1.605321] [<c0307a6c>] (__driver_attach) from [<c0305ea8>] (bus_for_each_dev+0x54/0x88) [ 1.613480] [<c0305ea8>] (bus_for_each_dev) from [<c0306e2c>] (bus_add_driver+0xec/0x200) [ 1.621640] [<c0306e2c>] (bus_add_driver) from [<c0308360>] (driver_register+0x78/0xf4) [ 1.629625] [<c0308360>] (driver_register) from [<c02f6e14>] (exynos_drm_init+0xb8/0x11c) [ 1.637785] [<c02f6e14>] (exynos_drm_init) from [<c0008a30>] (do_one_initcall+0xac/0x1ec) [ 1.645950] [<c0008a30>] (do_one_initcall) from [<c0974db4>] (kernel_init_freeable+0x194/0x268) [ 1.654626] [<c0974db4>] (kernel_init_freeable) from [<c0692e08>] (kernel_init+0x8/0xe4) [ 1.662699] [<c0692e08>] (kernel_init) from [<c000f040>] (ret_from_fork+0x14/0x34) [ 1.670246] Code: eaffffd5 c09df884 e92d40f0 e24dd01c (e5905350) [ 1.676408] ---[ end trace 804468492f306a6f ]--- [ 1.680948] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.680948] [ 1.690035] CPU1: stopping [ 1.692727] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123 [ 1.702097] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 1.708192] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14) [ 1.715908] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8) [ 1.723108] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4) [ 1.730485] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c) [ 1.738036] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74) [ 1.745498] Exception stack(0xee8fdf98 to 0xee8fdfe0) [ 1.750533] df80: 00000000 00000000 [ 1.758695] dfa0: ee8fdfe8 c0021780 c09df938 00000015 10c0387d c0a3d988 4000406a c09df8d4 [ 1.766853] dfc0: c0a27a74 c09df940 01000000 ee8fdfe0 c00101c0 c00101c4 60000113 ffffffff [ 1.775015] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c) [ 1.782397] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324) [ 1.790639] [<c005e804>] (cpu_startup_entry) from [<40008764>] (0x40008764) [ 1.797579] CPU0: stopping [ 1.800272] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123 [ 1.809642] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 1.815730] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14) [ 1.823450] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8) [ 1.830653] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4) [ 1.838030] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c) [ 1.845581] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74) [ 1.853043] Exception stack(0xc09ddf60 to 0xc09ddfa8) [ 1.858081] df60: 00000000 00000000 c09ddfb0 c0021780 c09df938 00000001 ffffffff c0a3d680 [ 1.866239] df80: c09c0dec c09df8d4 c0a27a74 c09df940 01000000 c09ddfa8 c00101c0 c00101c4 [ 1.874396] dfa0: 60000113 ffffffff [ 1.877872] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c) [ 1.885251] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324) [ 1.893499] [<c005e804>] (cpu_startup_entry) from [<c0974bc8>] (start_kernel+0x324/0x37c) [ 1.901655] [<c0974bc8>] (start_kernel) from [<40008074>] (0x40008074) [ 1.908161] CPU3: stopping [ 1.910855] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123 [ 1.920225] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 1.926313] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14) [ 1.934034] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8) [ 1.941237] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4) [ 1.948613] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c) [ 1.956165] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74) [ 1.963626] Exception stack(0xee901f98 to 0xee901fe0) [ 1.968661] 1f80: 00000000 00000000 [ 1.976823] 1fa0: ee901fe8 c0021780 c09df938 00000015 10c0387d c0a3d988 4000406a c09df8d4 [ 1.984982] 1fc0: c0a27a74 c09df940 01000000 ee901fe0 c00101c0 c00101c4 60000113 ffffffff [ 1.993143] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c) [ 2.000522] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324) [ 2.008765] [<c005e804>] (cpu_startup_entry) from [<40008764>] (0x40008764) [ 2.015710] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * | drm/exynos: fix typo config name correctly.Inki Dae2015-03-181-1/+1
| | | | | | | | | | | | | | | | | | This patch fixes DRM_EXYNOS7DECON to DRM_EXYNOS7_DECON. Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * | drm/exynos: Check for NULL dereference of crtcCharles Keepax2015-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the use of the enabled flag, which means that the code may attempt to call win_enable on a NULL crtc. This results in the following oops on Arndale: [ 1.673479] Unable to handle kernel NULL pointer dereference at virtual address 00000368 [ 1.681500] pgd = c0004000 [ 1.684154] [00000368] *pgd=00000000 [ 1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1.693012] Modules linked in: [ 1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.19.0-07545-g57485fa #1907 [ 1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (....) [ 2.014803] [<c02f9cfc>] (exynos_plane_destroy) from [<c02e61b4>] (drm_mode_config_cleanup+0x168/0x20c) [ 2.024178] [<c02e61b4>] (drm_mode_config_cleanup) from [<c02f66fc>] (exynos_drm_load+0xac/0x12c) This patch adds in a check to ensure exynos_crtc is not NULL before it is dereferenced. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * | drm/exynos: IS_ERR() vs NULL bugDan Carpenter2015-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | of_iomap() doesn't return error pointers, it returns NULL on error. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * | drm/exynos: remove unused filesAndrzej Hajda2015-03-182-265/+0
| |/ | | | | | | | | | | | | These files are not used anymore. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | drm/nouveau/bios: fix i2c table parsing for dcb 4.1Stefan Huehner2015-03-171-1/+5
| | | | | | | | | | | | | | | | | | Code before looked only at bit 31 to decide if a port is unused. However dcb 4.1 spec says 0x1F in bits 31-27 and 26-22 means unused. This fixed hdmi monitor detection on GM206. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)Stefan Huehner2015-03-171-0/+43
| | | | | | | | | | | | | | Enough to get VGA monitor on DVI-I output have output. HDMI output not yet working Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switchBen Skeggs2015-03-171-2/+4
| | | | | | | | | | | | fdo#88868 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addressesBen Skeggs2015-03-173-6/+6
| | | | | | | | | | | | fdo#83992 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/fifo/nv04: remove the loop from the interrupt handlerBen Skeggs2015-03-171-50/+35
|/ | | | | | | | | | | | | | | Complete bong hit (and not the last...), the hardware will reassert the interrupt to PMC if it's necessary. Also potentially harmful in the face of interrupts such as the non-stall interrupt, which remain active in NV_PFIFO_INTR even when we don't care about servicing it. It appears (hopefully, fdo#87244), that under certain loads, the methods may pass quickly enough to hit the "100 spins and kill PFIFO" thing that we had going on. Not ideal ;) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* [PATCH] drm/mm: Fix support 4 GiB and larger rangesKrzysztof Kolasa2015-03-161-1/+1
| | | | | | | | | | | | bad argument if(tmp)... in check_free_hole fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305! [airlied: excellent, this was my task for today]. Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2015-03-132-27/+47
|\ | | | | | | | | | | | | | | | | | | into drm-fixes Some additional radeon fixes for 4.0 * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: drop setting UPLL to sleep mode drm/radeon: fix wait to actually occur after the signaling callback
| * drm/radeon: drop setting UPLL to sleep modeChristian König2015-03-111-4/+2
| | | | | | | | | | | | | | | | | | | | Just keep it working, seems to fix some PLL problems. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378 Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| * drm/radeon: fix wait to actually occur after the signaling callbackMaarten Lankhorst2015-03-111-23/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A normal wait adds to the front of the tail. By doing something similar to fence_default_wait the fence code can run without racing. This is a complete fix for "panic on suspend from KDE with radeon", and a partial fix for "Radeon: System pauses on TAHITI". On tahiti si_irq_set needs to be fixed too, to completely flush the writes before radeon_fence_activity is called in radeon_fence_enable_signaling. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com> Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com> Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com> Cc: stable@vger.kernel.org (v3.18+) Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | Merge branch 'vmwgfx-fixes-4.0' of ↵Dave Airlie2015-03-133-57/+53
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~thomash/linux into drm-fixes A couple of fixes for vmwgfx. * 'vmwgfx-fixes-4.0' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Fix an issue with the device losing its irq line on module unload drm/vmwgfx: Correctly NULLify dma buffer pointer on failure drm/vmwgfx: Reorder device takedown somewhat drm/vmwgfx: Fix a couple of lock dependency violations
| * | drm/vmwgfx: Fix an issue with the device losing its irq line on module unloadThomas Hellstrom2015-03-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting with commit b4b55cda5874 ("x86/PCI: Refine the way to release PCI IRQ resources") the device lost its irq resource on module unload. While that's ok and apparently intentional, the driver never got the resource back on module load The code apparently wants drivers to disable the pci device at pci device driver removal, so lets do that. That fixes the issue. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
| * | drm/vmwgfx: Correctly NULLify dma buffer pointer on failureColin Ian King2015-03-111-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cppcheck on lines 917 and 977 show an ineffective assignment to the dma buffer pointer: [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]: [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]: (warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? On a successful DMA buffer lookup, the dma buffer pointer is assigned, however, on failure it currently is left in an undefined state. The original intention in the error exit path was to nullify the pointer on an error (which the original code failed to do properly). This patch fixes this also ensures all failure paths nullify the buffer pointer on the error return. Fortunately the callers to vmw_translate_mob_ptr and vmw_translate_guest_ptr are checking on a return status and not on the dma buffer pointer, so the original code worked. Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Colin Ian King <colin.king@canonical.com>
| * | drm/vmwgfx: Reorder device takedown somewhatThomas Hellstrom2015-03-111-37/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To take down the MOB and GMR memory types, the driver may have to issue fence objects and thus make sure that the fence manager is taken down after those memory types. Reorder device init accordingly. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
| * | drm/vmwgfx: Fix a couple of lock dependency violationsThomas Hellstrom2015-03-112-16/+6
| |/ | | | | | | | | | | | | | | | | | | | | Experimental lockdep annotation added to the TTM lock has unveiled a couple of lock dependency violations in the vmwgfx driver. In both cases it turns out that the device_private::reservation_sem is not needed so the offending code is moved out of that lock. Cc: <stable@vger.kernel.org> Acked-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
* | Merge tag 'drm-intel-fixes-2015-03-12' of ↵Dave Airlie2015-03-133-7/+28
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes More i915 fixes, three out of four are fixes to old bugs, cc: stable. * tag 'drm-intel-fixes-2015-03-12' of git://anongit.freedesktop.org/drm-intel: drm/i915: Prevent TLB error on first execution on SNB drm/i915: Do both mt and gen6 style forcewake reset on ivb probe drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again drm/i915: use in_interrupt() not in_irq() to check context
| * drm/i915: Prevent TLB error on first execution on SNBChris Wilson2015-03-101-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Long ago I found that I was getting sporadic errors when booting SNB, with the symptom being that the first batch died with IPEHR != *ACTHD, typically caused by the TLB being invalid. These magically disappeared if I held the forcewake during the entire ring initialisation sequence. (It can probably be shortened to a short critical section, but the whole initialisation is full of register writes and so we would be taking and releasing forcewake almost continually, and so holding it over the entire sequence will probably be a net win!) Note some of the kernels I encounted the issue already had the deferred forcewake release, so it is still relevant. I know that there have been a few other reports with similar failure conditions on SNB, I think such as References: https://bugs.freedesktop.org/show_bug.cgi?id=80913 v2: Wrap i915_gem_init_hw() with its own security blanket as we take that path following resume and reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
OpenPOWER on IntegriCloud