This was purely a kernel-internal type used in a early patch version
to add GEM bo mmap support. It was never used in-kernel in merged code
nor in userspace. Nuke it to align with kernel headers.
For reference the kernel patch:
commit 05f51722a154e73019434bd020e50ddb941046c5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Dec 11 11:34:32 2013 +0100
drm/bufs: remove handling of _DRM_GEM mappings
Gone with the new gem vma offset manager from David.
We can also ditch the uapi header definition from the enum since
userspace never used this. It ended up in there purely for historical
reasons (for reusing the old drm mmap code essentially), not because
userspace ever needed it.
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Update the UAPI header to the latest version in the Linux kernel. This
changes the struct drm_tegra_gem_mmap to properly handle offsets on 64-
bit architectures.
See commit bdf765071a8b ("drm/tegra: gem: Return 64-bit offset for
mmap(2)") in the Linux kernel (as of v4.1).
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
modetest was failing to work with driver because it wasn't in the
module list.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
These IDs were already part of the kernel since:
kernel commit 985dd4360fdf2533fe48a33a4a2094f2e4718dc0
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Jan 28 16:04:12 2016 +0200
drm/i915/bxt: update list of PCIIDs
Cc: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Share with upcoming CP tests.
v2: drop unnecessary forward declaration
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Android needs libdrm built statically for recovery;
enable that as well.
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Analogous to last two changes (amdgpu and radeon).
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jakob Bornecrantz <wallbraker@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Equivalent to the amdgpu commit before. Additionally, when libdrm is
installed to a 'non-default' location, users of libdrm_radeon will fail
to build, as radeon_cs.h (and maybe others) won't have their
dependencies (drm.h radeon_drm.h) fulfilled.
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Otherwise libdrm.so won't end up in the --libs, when one static links
libdrm_amdgpu.
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The headers were originally written in Mesa, imported to the kernel,
and improved upon in vc4-gpu-tools. These come from the v-g-t copies
and will replace the Mesa and v-g-t copies, and hopefully be used from
new tests in igt, as well.
v2: Fix linking against libdrm_intel instead of libdrm.
v3: Drop Libs and Cflags since they'll be inherited from libdrm.
v4: Switch to Requires.private. I was wrong about standard practice,
apparently only Intel was doing plain Requires (sorry to all
involved).
Signed-off-by: Eric Anholt <eric@anholt.net>
I'll build some libdrm C code soon, but for now this lets libdrm users
use vc4 ioctls. Produced from headers_install of
1df59b8497f47495e873c23abd6d3d290c730505 (drm-next) in the kernel.
Signed-off-by: Eric Anholt <eric@anholt.net>
The utils library depends on libdrm. Flip the order, orderwise we might
error during link stage like below:
CC main.o
CCLD kmstest
/usr/bin/ld: ../../tests/util/.libs/libutil.a(libutil_la-kms.o):
undefined reference to symbol 'drmOpen'
Reported-by: Tom Stellard <thomas.stellard@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Used in compliance with POSIX 2001/2008
Fixes errors e.g.
error: implicit declaration of function 'select'
and helps with missing definitions of FD_* defines
v2: conditionally include sys/select.h, include in every test where
needed.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
util_open() takes a device parameter, followed by a module parameter.
The existing tests used the drmOpen() function, which uses a different
ordering of the parameters, and the old ordering was accidentally kept
during the conversion.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Use the new util_open() helper instead of open-coding the method for
finding a usable device. While at it, make the command-line interface
more consistent with that of modetest by adding the -D and -M options.
Signed-off-by: Stefan Agner <stefan@agner.ch>
v2: correctly use util_open() - swap device, module
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Currently with --disable-amdgpu --disable-valgrind --disable-cairo-tests
cunit, valgrind and cairo are still detected.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
We are reading at most sizeof(data) bytes, but then data may not contain
a terminating '\0', at least in theory, so strstr() may overflow the
stack allocated array.
Make sure that data always contains at least one '\0'.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Not doing so makes it impossible for radeon_bo_open callers to set any
RADEON_GEM_* flags for the newly created BO.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: David Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>