Bionic libc ships with `ioctl` that has two signatures, one with an
unsigned `request` parameter and one with a signed request parameter.
This leads to compilation failing due to `__typeof__(ioctl)` being used
by DRM which fails to resolve which overload to use, this has been fixed
by defining `BIONIC_IOCTL_NO_SIGNEDNESS_OVERLOAD` on Android.
Signed-off-by: Mark Collins <mark@igalia.com>
There is an excellent writeup explaining this requirement here:
https://gitlab.freedesktop.org/wayland/wayland/-/issues/175
In short, for mixed environments such as the Steam Runtime and other
container-like environments, choosing which libdrm to link into the
client's address space is a hard problem. If the runtime has a newer
libdrm than the host, then it should be preferred, because the client
may be using newly-added symbols. But if the host has a newer libdrm,
then that should be used, because drivers may be depending on those.
Bumping the DSO minor version is transparent to all users because apps
only link against the major version, e.g. DT_NEEDED libdrm.so.2; the
fact that libdrm.so.2 is a link to libdrm.so.2.122.0 is a detail known
only to the loader, but it does let a smart runtime make better
decisions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When the GPU feature is turned on in crosvm, these modules are added as
dependencies. Since crosvm is included in the virt APEX, add the APEX to
the apex_available properties of the modules to make them available in
the APEX.
To do so, crosvm and its dependencies have the apex_available property
set to "//apex_available:platform", "com.android.virt" to explicitly
acknowledge the joining.
drm_property_type_is function in xf86drmMode.h file can cause compiler
error because it performs unsigned to signed conversion. Some Android.mk
modules have been avoiding this by adding "-isystem external/libdrm"
flag, because warnings from system headers are suppressed.
This changes exported_include_dirs to export_system_include_dirs
to workaround the potential error with the same manner above.
... to make drm format header visible for host wayland server.
Adds -Wno-implicit-function-declaration for vasprintf() on
xf86drm.c:2965.
Adds -Wno-int-conversion for drm_mmap() on libdrm_macros.h:60.
Also, drive-by alphabetize cflags.
See build/soong/README.md for more information about Soong.
Removes BOARD_GPU_DRIVERS, which wasn't affecting anything, since none
of the HAVE_* macros are defined. Even if they were, we'd prefer to
compile all of them so that a single library can support multiple
boards.
Some platforms (eg. SunOS) explicitly need extra symbols in order to define
those functions. There're many files needing the __EXTENSIONS__ symbol,
so doing this on a global scale.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Synchronize drm_fourcc.h and drm_mode.h to drm-next.
Generated using make headers_install.
Generated from drm-next branch commit 541b1b0a8fc235bca355921eb7f3f59a8efa3e9a
Signed-off-by: Simon Ser <contact@emersion.fr>
The <linux/fb.h> header only exists on Linux, but isn't used anymore,
so drop it entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several drivers still including <linux/stddef.h>, but not using anything
from it, thus breaking build on non-Linux platforms (eg. FreeBSD).
Since not needed at all, just stop including it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
../xf86drm.c:4622:9: error: use of undeclared identifier 'written'; did you mean 'write'?
if (written + 1 > max_node_length)
^~~~~~~
write
../xf86drm.c:4624:21: error: use of undeclared identifier 'sbuf'; did you mean 'sbrk'?
if (stat(node, &sbuf))
^~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
fix commit cc3c80c6("tests/amdgpu: refactor dispatch/draw test")
../../SOURCES/drm/tests/amdgpu/shader_code.h:113:2: error: initializer
element is not constant
ps_##_ps##_shader_patchinfo_code_size_gfx##_n, \
^
Signed-off-by: Flora Cui <flora.cui@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
../../drm/tests/amdgpu/shader_test_util.c: In function
‘amdgpu_dispatch_init’:
../../drm/tests/amdgpu/shader_test_util.c:296:9: warning: enumeration
value ‘AMDGPU_TEST_GFX_MAX’ not handled in switch [-Wswitch]
296 | switch (test_priv->info->version) {
| ^~~~~~
Signed-off-by: Flora Cui <flora.cui@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The issue was found by a static analysis tool:
Error: LOCK_EVASION (CWE-543):
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: thread1_checks_field:
Thread1 uses the value read from field "context" in the
condition "sem->signal_fence.context". It sees that the
condition is false. Control is switched to Thread2.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: thread2_checks_field:
Thread2 uses the value read from field "context" in the
condition "sem->signal_fence.context". It sees that the
condition is false.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:598: thread2_acquires_lock:
Thread2 acquires lock "amdgpu_context.sequence_mutex".
libdrm-2.4.115/amdgpu/amdgpu_cs.c:599: thread2_modifies_field:
Thread2 sets "context" to a new value. Note that this write can
be reordered at runtime to occur before instructions that do
not access this field within this locked region. After Thread2
leaves the critical section, control is switched back to
Thread1.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:598: thread1_acquires_lock:
Thread1 acquires lock "amdgpu_context.sequence_mutex".
libdrm-2.4.115/amdgpu/amdgpu_cs.c:599: thread1_overwrites_value_in_field:
Thread1 sets "context" to a new value. Now the two threads have
an inconsistent view of "context" and updates to fields of
"context" or fields correlated with "context" may be lost.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: use_same_locks_for_read_and_modify:
Guard the modification of "context" and the read used to decide
whether to modify "context" with the same set of locks.
# 597| return -EINVAL;
# 598| pthread_mutex_lock(&ctx->sequence_mutex);
# 599|-> sem->signal_fence.context = ctx;
# 600| sem->signal_fence.ip_type = ip_type;
# 601| sem->signal_fence.ip_instance = ip_instance;
Check `sem->signal_fence.context` in the locked region to avoid a race
condition.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
I always need to double-check what the return value means when
using that function (since it's not a bool).
Signed-off-by: Simon Ser <contact@emersion.fr>
str.format used to allow any type as an argument, which often resulted
in using an internal string representation. This is considered broken
behavior, and is deprecated since Meson 1.3.0.
Signed-off-by: Joaquim Monteiro <joaquim.monteiro@protonmail.com>
The devices weren't removed from dev_list.
Instead of just fixing the issue by adding:
if (*node) *node = dev->next;
after the while loop, use this opportunity to use a clearer
control flow.
Fixes: 7275ef8e ("amdgpu: add amdgpu_device_initialize2")
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Allows to opt-out from the device deduplication logic. This is not the
recommended way of using dev handles, but it's necessary for native context:
in this situation one process (eg: Qemu) will init many devices and we
want independent devices to make sure guest applications are isolated from
each other.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is the same functionnality that amdgpu_va_range_alloc offers,
except it's now usable without a device handle.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This will allow applications to use this feature without a device.
The first use case will be native context: we want VA address to
be managed by the guest (to avoid a round-trip to the host to only
generate a VA) but the amdgpu_device only exist on the host.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Until now VA management was tied to a device handle, but there's no
reason for this.
As a first step to export VA management outside of amdgpu_device,
this commit adds a new structure type holding the 4 va_mgr.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Device will be removed from dev_list when refcount reaches 0, so the
dev_mutex must be locked before decreasing reference otherwise there's
a race where this device is still in dev_list with refcount 0 which will
assert or crash in amdgpu_device_initialize trying to use this device
instead of creating new one.
Fixes issue reported in https://gitlab.freedesktop.org/drm/amd/-/issues/2156#note_2268110
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Add an entry for the "tidss" driver, so that the test utilities work
with this driver without passing the -M argument.
Signed-off-by: Francesco Valla <valla.francesco@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
This fixes the logic that decides if a node name is valid to use the
same length restrictions that are used in drmDeviceAlloc, which expects
node names to conform to a specific naming scheme (On OSes except
OpenBSD this means `/dev/dri/renderD123`). This addresses the problem of
node names that are longer than expected, while still allowing symlinks
to work.
I've also applied the same fix to the OpenBSD path, while bringing the
check that `snprintf` didn't error from OpenBSD to the main path.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Tested-by: Mark Janes <markjanes@swizzler.org>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
This reverts commit 7ab1cdac90.
This breaks numerous tools that rely on being able to read symlinks, and
constitutes a regression.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Tested-by: Mark Janes <markjanes@swizzler.org>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Closes: #103
If the user has some UDev rules in place that creates symlinks for
one of the card or render nodes, and the name of the symlink is
too long, then drmDeviceAlloc() ends up truncating the name of
the node.
This in turn results in chaos in different subsystems. E.g.
vulkaninfo dies early with this:
Code 0 : failed to stat DRM primary node /dev/dri/my-favorite- (VK_ERROR_INITIALIZATION_FAILED)
(if the symlink is called /dev/dri/my-favorite-card-node)
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
