summaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2011-10-26 00:53:57 +0200
committerDave Airlie <airlied@redhat.com>2012-07-20 04:50:47 +0200
commit4c373790a4d4d667d1ab38b1fe2bbf6a8322e93b (patch)
tree19d122639cb74a5c2cc49f8e32fbea2d8b242053 /drivers
parentdrm: kill reclaim_buffers callback (diff)
downloadlinux-4c373790a4d4d667d1ab38b1fe2bbf6a8322e93b.tar.xz
linux-4c373790a4d4d667d1ab38b1fe2bbf6a8322e93b.zip
drm: ditch strange DRIVER_DMA_QUEUE only error bail-out
Only one driver (i810) even sets that flag. Now the actual locking code uncoditionally promotes lock->context to an unsigned int. Closer inspection of the userspace reveals that the drm lock context is defined as an unsigned int (at least on linux). I suspect we just have a strange case of signedness confusion going on. Tested on my i815, doesn't seem to break anything. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/gpu/drm/drm_lock.c4
1 files changed, 0 insertions, 4 deletions
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 521152041691..32039553e172 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -70,10 +70,6 @@ int drm_lock(struct drm_device *dev, void *data, struct drm_file *file_priv)
lock->context, task_pid_nr(current),
master->lock.hw_lock->lock, lock->flags);
- if (drm_core_check_feature(dev, DRIVER_DMA_QUEUE))
- if (lock->context < 0)
- return -EINVAL;
-
add_wait_queue(&master->lock.lock_queue, &entry);
spin_lock_bh(&master->lock.spinlock);
master->lock.user_waiters++;