| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit c86dabfc9f04 ("omap: zero is a valid fd number, treat it as
such") corrected checks for valid file descriptors, but the OMAP buffer
object code initializes the DMA-BUF file descriptor to 0 (as a result of
calloc()'ing the structure). Obviously this isn't going to work because
subsequent code will try to use file descriptor 0 (most likely stdin at
that point) as a DMA-BUF. It may also try and close stdin when a buffer
object is destroyed.
Fix this by initializing the DMA-BUF file descriptor to -1, properly
marking it as an invalid file descriptor.
Fixes: c86dabfc9f04 ("omap: zero is a valid fd number, treat it as such")
Reported-by: Robert Nelson <robertcnelson@gmail.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Equivalent to the previous patch.
Cc: Rob Clark <robdclark@gmail.com>
Suggested-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
|
|
Some compilers (like the Oracle Studio), require that the function
declaration must be annotated with the same visibility attribute as the
definition. As annotating functions with drm_public is no longer
required just remove the macro.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
With earlier commits we've annotated the private symbols, thus
we no longer require the -fvisibility=hidden CFLAGS.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Provide a more meaningful name, considering what it does.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Already handled by the build system.
v2: s/compiler/build system/
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
No changes to exported symbols.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
|
|
Signed-off-by: Rob Clark <rob@ti.com>
|
|
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>
|
|
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>
|
|
Signed-off-by: Rob Clark <rob@ti.com>
|
|
Signed-off-by: Rob Clark <rob@ti.com>
|
|
Signed-off-by: Rob Clark <rob@ti.com>
|
|
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>
|
|
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>
|
|
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>
|
