summaryrefslogtreecommitdiff
path: root/omap
AgeCommit message (Collapse)Author
2015-04-28omap: add symbols testEmil Velikov
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
2015-03-20autotools: remove ${srcdir} from the includesEmil Velikov
Already handled by the build system. v2: s/compiler/build system/ Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
2014-08-14omap: Use symbol visibility.Maarten Lankhorst
No changes to exported symbols. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
2012-10-09omap: release lock also on error pathsVincent Penquerc'h
Signed-off-by: Rob Clark <rob@ti.com>
2012-08-23omap: include omap_drm.h independentlyVíctor Manuel Jáquez Leal
omap_drm.h uses data type defined in stdint.h, but that header was not included. omap_drm.h includes drm.h as a local file when it is part of the compiler c flags. This two issues are fixed. New code can include omap_drm.h alone. Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Signed-off-by: Rob Clark <rob@ti.com>
2012-07-13omap: add refcnting and handle trackingRob Clark
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>
2012-07-13omap: add API to import bo's from dmabuf fd'sRob Clark
Signed-off-by: Rob Clark <rob@ti.com>
2012-07-13omap: clarify dmabuf file descriptor ownershipRob Clark
Signed-off-by: Rob Clark <rob@ti.com>
2012-04-11omap: add dmabuf supportRob Clark
Signed-off-by: Rob Clark <rob@ti.com>
2012-04-03omap: fix compiler warningVíctor Manuel Jáquez Leal
When compiling with linaro toolchain version 4.6.2 got this warning. CC omap_drm.lo omap_drm.c: In function 'omap_bo_new_impl': omap_drm.c:139:6: warning: 'bo' may be used uninitialized in this function [-Wuninitialized] This patch initialize bo to NULL avoiding the warning. Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Signed-off-by: Rob Clark <rob@ti.com>
2012-04-03omap: fix license headerRob Clark
In syncing with the corresponding kernel header, the wrong license header was inadvertantly copied over. The intention was for the userspace headers to have a MIT license following the convention of the rest of libdrm, xorg, etc. Signed-off-by: Rob Clark <rob@ti.com>
2012-03-28omap: add omapdrm supportRob Clark
This adds libdrm_omap helper layer (as used by xf86-video-omap, omapdrmtest, etc). Signed-off-by: Rob Clark <rob@ti.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> [danvet: pushed for Rob, he doesn't yet have commit access.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>