- Sep 16, 2015
-
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
- Sep 12, 2015
-
-
Alan Coopersmith authored
Fixes "error: implicit declaration of function 'alloca'" failures when building on Solaris Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
-
- Sep 09, 2015
-
-
Sync up with new kernel features as per commits: e3eb3250d84ef97b766312345774367b6a310db8 93b81f5102a7cd270a305c2741b17c8d44bb0629 b5ff6e1637b683d5996ae11ac29afe406c0bee90 8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e 570655b09b065d2fff1b8ab9bdb8308f4c5a05a3 Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Rob Clark <robdclark@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Fixes build failure due to unresolved log2. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Sep 04, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
We're about to remove the -Wno flag from configure.ac which will lead to a lot of unnecessary spam. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Cc: nouveau@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
In the latest version of CUnit the fourth parameter of the CU_SuiteInfo struct is pSetUpFunc rather than *pTests. Seems like the CUnit ABI broke at some point, so let's the the robust thing and use c99 designated initializers to correctly populate the struct(s). Cc: Leo Liu <leo.liu@amd.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Emil Velikov authored
The remaining two templates are modified on the fly, depending on the type of test to be performed. Cc: Leo Liu <leo.liu@amd.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Emil Velikov authored
Cc: Leo Liu <leo.liu@amd.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Emil Velikov authored
Cc: Leo Liu <leo.liu@amd.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Emil Velikov authored
Cc: freedreno@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Annotate the data as static const and use C99 designated initializers. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
...to minimise misuse of bo_gem. If the variable is declared at the top of the function and then used for two (or more) different contexts this can cause confusion and errors. Just introduce a wrapper, which can be used in a once off situations. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
-
Emil Velikov authored
Just like we do for the original exec() v2: move bo_gem declaration to the top of the function. Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
-
Emil Velikov authored
v2: keep the bo_gem declaration in exec2() within the loop (Chris) Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
-
Emil Velikov authored
No real issue here, but let's fix these so that real issues don't get lost in the spam. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Just remove the second (shadowing) declaration of ret. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
For android / drm_gralloc, we want to hook up our own debug_print() without bothering with the reset of it. Signed-off-by: Rob Clark <robdclark@gmail.com>
-
- Sep 03, 2015
-
-
Rob Clark authored
EGL_EXT_image_dma_buf_import specifies that the importer retains ownership of the fd, rather then the importee. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
- Sep 02, 2015
-
-
Jonathan Gray authored
EBADMSG is a streams errno. OpenBSD does not implement streams and does include the streams errnos, this commit fixes the build on OpenBSD. None of the callers of this function check the return value for -EBADMSG. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
-
monk.liu authored
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: monk.liu <monk.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
- Aug 31, 2015
-
-
fixes the prime sharing race condition described by "intel: Serialize drmPrimeFDToHandle with struct_mutex". we inline fd_bo_from_handle() into fd_bo_from_dmabuf() and allow locking. Signed-off-by: Varad Gautam <varadgautam@gmail.com> Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
don't call drmIoctl() directly for prime bo's, use the wrappers instead. v3: remove struct drm_prime_handle and split locking Signed-off-by: Varad Gautam <varadgautam@gmail.com> Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
- Aug 26, 2015
-
-
Thierry Reding authored
Commit c86dabfc ("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: c86dabfc ("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>
-
- Aug 25, 2015
-
-
Christian König authored
Fixes the same problem as "intel: Serialize drmPrimeFDToHandle with struct_mutex". Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
-
Christian König authored
It's not used any more. Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
-
- Aug 24, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Jérôme Glisse authored
Last commit (b556ea12) introduced use of log2 which require -lm flag for the linker on quite few distribution. Just add that flag to fix build. Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
-
Emil Velikov authored
For mutiple GPU support, the devices on the system should be enumerated to get necessary information about each device, and the drmGetDevices interface is added for this. Currently only PCI devices are supported for the enumeration. Typical usage: int count; drmDevicePtr *foo; count = drmGetDevices(NULL, 0); foo = calloc(count, sizeof(drmDevicePtr)); count = drmGetDevices(foo, count); /* find proper device, open correct device node, etc */ drmFreeDevices(foo, count); free(foo); v2: [Jammy Zhou] - return a list of devices, rather than nodes v3: [Jammy Zhou] - fix the signed extension for PCI device info Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
-
For readdir_r(), the next directory entry is returned in caller-allocted buffer (pointered by pent here). https://bugs.freedesktop.org/show_bug.cgi?id=91704 Signed-off-by: Mathias Tillman <master.homer@gmail.com> Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
-
- Aug 23, 2015
-
-
Signed-off-by: Varad Gautam <varadgautam@gmail.com> Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Signed-off-by: Varad Gautam <varadgautam@gmail.com> Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Importing a bo whose handle is still in the bo cache crashes during cleanup. Remove bo from cache when importing. Signed-off-by: Varad Gautam <varadgautam@gmail.com> Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
- Aug 21, 2015
-
-
Rafał Sapała authored
It is possible to hit a race condition in create_from_prime, when trying to import a BO that's currently being freed. In case of prime sharing we'll succesfully get a handle, but fail on get_tiling call, potentially confusing the caller (and requiring different locking scheme than with sharing using flink). Wrap fd_to_handle with struct_mutex to force a more consistent behaviour between prime/flink, convert fprintf to DBG when handling errors. (From Chris: The race is that the kernel returns us the same file-private handle as the first thread, but that first thread is about to call gem_close (thereby removing the handle from the file completely) and does so between us acquiring the handle and taking the mutex. If we take the mutex, then we acquire the refcnt on the bo prior to the first thread completing its unref (and so preventing the early close). Or we acquire the handle after the earlier close, in which case we are the new owner. ) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Testcase: igt/drm_import_export/import-close-race-prime Signed-off-by: Rafał Sapała <rafal.a.sapala@intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
-