linux-toradex.git/include/drm/drmP.h, branch v2.6.37-rc3

Merge remote branch 'korg/drm-fixes' into drm-vmware-next

2010-10-06T01:10:48+00:00

necessary for some of the vmware fixes to be pushed in.

Conflicts:
	drivers/gpu/drm/drm_gem.c
	drivers/gpu/drm/i915/intel_fb.c
	include/drm/drmP.h

drm: Move the GTT accounting to i915

2010-10-01T13:45:20+00:00

Only drm/i915 does the bookkeeping that makes the information useful,
and the information maintained is driver specific, so move it out of the
core and into its single user.

Signed-off-by: Chris Wilson 
Cc: Dave Airlie

drm: Hold the mutex when dropping the last GEM reference (v2)

2010-10-01T11:08:45+00:00

In order to be fully threadsafe we need to check that the drm_gem_object
refcount is still 0 after acquiring the mutex in order to call the free
function. Otherwise, we may encounter scenarios like:

Thread A:                                        Thread B:
drm_gem_close
unreference_unlocked
kref_put                                         mutex_lock
...                                              i915_gem_evict
...                                              kref_get -> BUG
...                                              i915_gem_unbind
...                                              kref_put
...                                              i915_gem_object_free
...                                              mutex_unlock
mutex_lock
i915_gem_object_free -> BUG
i915_gem_object_unbind
kfree
mutex_unlock

Note that no driver is currently using the free_unlocked vfunc and it is
scheduled for removal, hasten that process.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30454
Reported-and-Tested-by: Magnus Kessler 
Signed-off-by: Chris Wilson 
Cc: stable@kernel.org
Signed-off-by: Dave Airlie

drm/gem: handlecount isn't really a kref so don't make it one.

2010-09-30T23:17:44+00:00

There were lots of places being inconsistent since handle count
looked like a kref but it really wasn't.

Fix this my just making handle count an atomic on the object,
and have it increase the normal object kref.

Now i915/radeon/nouveau drivers can drop the normal reference on
userspace object creation, and have the handle hold it.

This patch fixes a memory leak or corruption on unload, because
the driver had no way of knowing if a handle had been actually
added for this object, and the fbcon object needed to know this
to clean itself up properly.

Reviewed-by: Chris Wilson 
Signed-off-by: Dave Airlie

drm: Prune GEM vma entries

2010-09-27T23:14:34+00:00

Hook the GEM vm open/close ops into the generic drm vm open/close so
that the private vma entries are created and destroy appropriately.
Fixes the leak of the drm_vma_entries during the lifetime of the filp.

Reported-by: Matt Mackall 
Cc: Jesse Barnes 
Signed-off-by: Chris Wilson 
Acked-by: Jesse Barnes 
Cc: stable@kernel.org
Signed-off-by: Dave Airlie

drm: kill get_reg_ofs callback

2010-08-29T23:44:56+00:00

Every driver used the default implementation. Fold that one into
the only callsite and drop the callback.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: kill dev->timer

2010-08-29T23:44:54+00:00

Totally unused.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: kill agp indirection mess

2010-08-29T23:44:40+00:00

There's no point in jumping through two indirections. So kill one
and call the kernels agp functions directly.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: replace drawable ioctl by noops

2010-08-29T23:39:11+00:00

The information supplied by userspace through these ioctls is only
accessible by dev->drw_idr. But there's no in-tree user of that.
Also userspace does not really care about return values of these ioctls,
either. Only hw/xfree86/dri/dri.c from the xserver actually checks the
return from adddraw and keeps on trying to create a kernel drawable
every time somebody creates a dri drawable. But since that's now a noop,
who cares.

Therefore it's safe to replace these three ioctls with noops and rip
out the implementation.

Signed-off-by: Daniel Vetter 
Reviewed-by: Kristian Høgsberg 
Reviewed-by: Michel Dänzer 
Signed-off-by: Dave Airlie

drm: don't export dri1 locking functions

2010-08-29T23:39:00+00:00

Only used by ioctl, not by any in-tree drivers.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie