omap: add refcnting and handle tracking properties
authorRob Clark <rob@ti.com>
Wed, 13 Jun 2012 21:17:27 +0000 (16:17 -0500)
committerRob Clark <rob@ti.com>
Tue, 26 Jun 2012 13:50:48 +0000 (08:50 -0500)
commitff3c87d3e7445a98d783b62961517760b599dade
tree7ace9e5b9c827849ae581791d79f44e2a3652a7d
parent6574d5389f563ade96ae10e61cb7a1712f6d46a2
omap: add refcnting and handle tracking

There can be scenarios, especially when re-importing an existing buffer,
where you end up with multiple 'struct omap_bo's wrapping a single GEM
object handle.  Which causes badness when the first of the evil-clones
is omap_bo_del()'d.

To do this, introduce reference counting and a hashtable to track the
handles per fd.

First, to avoid bo's slipping through the crack if multiple 'struct
omap_device's are created for one drm fd, a hashtable mapping drm
fd to omap_device, and the omap_device itself is reference counted.
Per omap_device, we keep a handle_table mapping GEM handle to omap_bo.
When buffers are imported from flink name or dmabuf fd, the handle
table is consulted, and if an omap_bo already exists, it's refcnt is
incremented and it is returned.  For good measure, to avoid the
handle_table being deleted before the omap_bo is freed, the omap_bo
holds a reference to the omap_device.

TODO: check the overhead of the hashtable.  If too much we could maybe
get away with only tracking exported and imported bo's in the table.

TODO: all the import/export flink/dmabuf operations are generic DRM
ioctls.  Really all this functionality could be handled by a generic
drm_bo and drm_device "base class" that could be extended by omap,
exynos, etc.  That would also allow more common userspace code by
avoiding artificial libdrm_omap dependencies.
configure.ac
omap/omap_drm.c
omap/omap_drmif.h