summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
AgeCommit message (Collapse)Author
2015-11-02drm/vmwgfx: Replace iowrite/ioread with volatile memory accessesThomas Hellstrom
Now that we use memremap instead of ioremap, Use WRITE_ONCE / READ_ONCE instead of iowrite / ioread. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2015-08-12drm/vmwgfx: Fix copyright headersSinclair Yeh
Updating and fixing copyright headers. Bump version minor to signal vgpu10 support. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2015-08-05drm/vmwgfx: Kill a bunch of sparse warningsThomas Hellstrom
We're giving up all attempts to keep cpu- and device byte ordering separate. This silences sparse when compiled using make C=2 CF="-D__CHECK_ENDIAN__" Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2015-01-19drm/vmwgfx: Replace the hw mutex with a hw spinlockThomas Hellstrom
Fixes a case where we call vmw_fifo_idle() from within a wait function with task state !TASK_RUNNING, which is illegal. In addition, make the locking fine-grained, so that it is performed once for every read- and write operation. This is of course more costly, but we don't perform much register access in the timing critical paths anyway. Instead we have the extra benefit of being sure that we don't forget the hw lock around register accesses. I think currently the kms code was quite buggy w r t this. This fixes Red Hat Bugzilla Bug 1180796 Cc: stable@vger.kernel.org Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
2014-12-03drm/vmwgfx: Fix fence event codeThomas Hellstrom
The commit "vmwgfx: Rework fence event action" introduced a number of bugs that are fixed with this commit: a) A forgotten return stateemnt. b) An if statement with identical branches. Cc: <stable@vger.kernel.org> Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2014-12-03drm/vmwgfx: Don't use memory accounting for kernel-side fence objectsThomas Hellstrom
Kernel side fence objects are used when unbinding resources and may thus be created as part of a memory reclaim operation. This might trigger recursive memory reclaims and result in the kernel running out of stack space. So a simple way out is to avoid accounting of these fence objects. In principle this is OK since while user-space can trigger the creation of such objects, it can't really hold on to them. However, their lifetime is quite long, so some form of accounting should perhaps be implemented in the future. Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 with low system memory settings. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2014-09-02drm/vmwgfx: rework to new fence interface, v2Maarten Lankhorst
Use the new fence interface on vmwgfx too. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> --- Changes since v1: Fix a sleeping function called from invalid context in enable_signaling.
2014-09-02drm/vmwgfx: get rid of different types of fence_flags entirelyMaarten Lankhorst
Only one type was ever used. This is needed to simplify the fence support in the next commit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
2014-01-08drivers: gpu: Mark functions as static in vmwgfx_fence.cRashika Kheria
Mark functions as static because they are not used outside the file drm/vmwgfx/vmwgfx_fence.c. This eliminates the following warnings in drm/vmwgfx/vmwgfx_fence.c: drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:274:6: warning: no previous prototype for ‘vmw_fences_perform_actions’ [-Wmissing-prototypes] drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:900:6: warning: no previous prototype for ‘vmw_fence_obj_add_action’ [-Wmissing-prototypes] drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:996:5: warning: no previous prototype for ‘vmw_event_fence_action_create’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
2014-01-08drm/ttm: ttm object security fixes for render nodesThomas Hellstrom
When a client looks up a ttm object, don't look it up through the device hash table, but rather from the file hash table. That makes sure that the client has indeed put a reference on the object, or in gem terms, has opened the object; either using prime or using the global "name". To avoid a performance loss, make sure the file hash table entries can be looked up from under an RCU lock, and as a consequence, replace the rwlock with a spinlock, since we never need to take it in read mode only anymore. Finally add a ttm object lookup function for the device hash table, that is intended to be used when we put a ref object on a base object or, in gem terms, when we open the object. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2012-11-28drm/vmwgfx: Free user-space fence objects correctlyThomas Hellstrom
They need to be freed after an rcu grace period. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-10-02UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
2012-09-26vmwgfx: corruption in vmw_event_fence_action_create()Dan Carpenter
We don't allocate enough data for this struct. As soon as we start modifying event->event on the next lines, then we're going beyond the end of the memory we allocated. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@gmail.com>
2012-02-13vmwgfx: Clean up pending event references to struct drm_file objects on closeThomas Hellstrom
Pending events may have stale pointer references to struct drm_file objects after a file has been closed, but before the event is supposed to be attached to the drm file. Remove such events on file close. Tested with "modetest". Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-13vmwgfx: Rework fence event actionJakob Bornecrantz
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-10-18vmwgfx: memory leaks caused by double allocationDan Carpenter
These variables get allocated twice so the first allocation is a memory leak. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-10-10vmwgfx: Add fence eventsThomas Hellstrom
Add a way to send DRM events down the gpu fifo by attaching them to fence objects. This may be useful for Xserver swapbuffer throttling and page-flip done notifications. Bump version to 2.2 to signal the availability of the FENCE_EVENT ioctl. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-10-05vmwgfx: Allow reference and unreference of NULL fence objects.Thomas Hellstrom
The execbuf utils may call reference on NULL fence objects. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-09-06vmwgfx: Implement fence objectsThomas Hellstrom
Will be needed for queries and drm event-driven throttling. As a benefit, they help avoid stale user-space fence handles. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-09-06vmwgfx: Fix confusion caused by using "fence" in various placesThomas Hellstrom
This is needed before we introduce the fence objects. Otherwise this will be even more confusing. The plan is to use the following: seqno: A 32-bit sequence number that may be passed in the fifo. marker: Objects, carrying a seqno, that track fifo submission time. They are used for fifo lag based throttling. fence objects: Kernel space objects, possibly accessible from user-space and carrying a 32-bit seqno together with signaled status. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-06-01drm/vmwgfx: Add kernel throttling support. Bump minor.Thomas Hellstrom
The throttle_us member in the execbuf argument is now honored. If the member is 0, no waiting for lag will occur, which guarantees backwards compatibility with well-behaved clients. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>