summaryrefslogtreecommitdiff
path: root/m4
diff options
context:
space:
mode:
authorRob Clark <rob@ti.com>2012-07-13 16:18:25 -0500
committerRob Clark <rob@ti.com>2012-07-13 16:18:25 -0500
commit22574aa887efa879519328acc09cb01d03374bf4 (patch)
treeaf4cdcdf552663204fe271fd5fac884257c09050 /m4
parent42f8a68e19ba48a25f5eca2778d997f3d1ad094d (diff)
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. Signed-off-by: Rob Clark <rob@ti.com>
Diffstat (limited to 'm4')
0 files changed, 0 insertions, 0 deletions