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>
Synchronize drm.h and drm_mode.h to drm-next.
Generated using make headers_install.
Generated from drm-next branch commit a60501d7c2d3e70b3545b9b96576628e369d8e85
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Simon Zeni <simon.zeni@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Synchronize drm.h, drm_mode.h and drm_fourcc.h to drm-next.
Generated using make headers_install.
Generated from drm-next branch commit c79b972eb88b077d2765e7790d0902b3dc94d55c
Signed-off-by: Simon Ser <contact@emersion.fr>
This is useful to figure out whether the dev_t refers to a primary
node or a render node. Indeed, drmGetDeviceFromDevId returns a
drmDevice, which holds both the primary and render nodes.
Signed-off-by: Simon Ser <contact@emersion.fr>
