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>
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>
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>
...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>
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>
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>
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>
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>
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>
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>
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>
Commit c86dabfc9f ("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: c86dabfc9f ("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>
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>
Last commit (b556ea127e) 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>
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>
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>
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>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
[Emil Velikov: remove duplicate amdgpu.h from LIBDRM_AMDGPU_FILES]
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Use tabs and spaces consistently to align function arguments on
subsequent lines with those of the first line.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Usage of blank lines can be a matter of taste, of course, but for these
we can surely all agree that they're not needed and inconsistent.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Each device can have its own vamgr, so make it per device now.
This can fix the failure with multiple GPUs used in one single
process.
v2: rebase
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The AMDGPU_VA_RANGE_32_BIT flag is added to request VA range in the
32bit address space for amdgpu_va_range_alloc.
The 32bit address space is reserved at initialization time, and managed
with a separate VAMGR as part of the global VAMGR. And if no enough VA
space available in range above 4GB, this reserved range can be used as
fallback.
v2: add comment for AMDGPU_VA_RANGE_32_BIT, and add vamgr to va_range
v3: rebase to Emil's drm_private series
v4: fix one warning
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Make it a generic function independent of the device info.
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
User should only see these with LIBGL_DEBUG=verbose. But in case you
are hitting issues like "handle X at index Y already on submit list"
errors from the kernel, this gives some useful visibility for debug.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
It should be a less common case, but it is possible for a single bo to
be on multiple rings, for example when sharing a buffer across multiple
pipe_context's created from same pipe_screen.
So rather than completely fall over in this case, fallback to slow-path
of looping over all bo's in the ring's bo-table (but retain the fast-
path of constant-lookup for the first ring the buffer is on).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Group the parts related to building out submit ioctl into their own
sub-struct. Split out from next commit since it is just boring churn.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Emil Velikov
Rob Clark
Rob Clark
Jonathan Gray
monk.liu
Varad Gautam
Thierry Reding
Christian König
Jérôme Glisse
Mathias Tillman
Rafał Sapała
Hyungwon Hwang
Mauro Rossi
Jammy Zhou
Michel Dänzer