Otherwise we get an EFAULT, at least on a 64-bit kernel.
Fixes: 2048a9e7 "drm: add drmSyncobjWait wrapper"
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Otherwise we'll end up without the macros set during configure stage.
And effectively error out in sanity tests such as the mmap static
assert.
To reproduce, do a multilib build - 32bit build on 64bit machine.
Cc: Fabio Pedretti <pedretti.fabio@gmail.com>
Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Fixes: 33dcc29f7c ("amdgpu: Add VMID reservation per GPU context test.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104819
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
While at it, align with the other half on the next line.
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In case of a kernel that is new enough to support multiple submit-
queues, but with an adreno generation which doesn't support multiple
prioritized ringbuffers, we'd attempt to open a submit-queue with
prio=1 (medium), which is rejected by the kernel.
This could happen either w/ an older mesa (which uses fd_pipe_new())
or a newer mesa which defaults to prio=1 if no pipe context priority
flags are set.
The simple answer to fix both cases is to clamp the requested priority
according to the number of rings. This might not do exactly what you
want, if we hypothetically had 2 rings (it would result in requested
medium priority being high priority instead of low priority). But the
number of rings (for hw gen's that support this) is purely a software
construct, so the easy answer there is to have the kernel advertise at
least 3 rings if it supports more than one. There isn't really any
reason to do otherwise.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
If amdgpu_cs_query_fence_status terminates prematurely the BO
sometimes is unmapped before helper thread writes a vlaue
into it causing a segfault.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Kernel will abort jobs for guilty (causing GPU hang) context
with -ECANCELED don't assert if that the case.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Currently we ask for 0.42, but we actually require 0.43 because we pass
file objects as arguments to tests. If someone needs version 0.42 it
wouldn't be hard, just a lot of replacing files() with strings.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Copy and paste error from exynos.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
There is warning about ignoring return value of 'asprintf'. Fix to
check return value of asprintf().
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
That constant needs to be 64bits.
Fixes: amdgpu: use the high VA range if possible v2
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Fixes use after free:
==2537== Invalid read of size 4
==2537== at 0x1162C9: suite_deadlock_tests_enable (deadlock_tests.c:101)
==2537== by 0x10B157: amdgpu_disable_suits (amdgpu_test.c:421)
==2537== by 0x10B157: main (amdgpu_test.c:560)
==2537== Address 0x5e44f24 is 452 bytes inside a block of size 1,016 free'd
==2537== at 0x4C2BE1B: free (vg_replace_malloc.c:530)
==2537== by 0x504CD8B: amdgpu_device_reference (amdgpu_device.c:164)
==2537== by 0x504CD8B: amdgpu_device_deinitialize (amdgpu_device.c:307)
==2537== by 0x1162BB: suite_deadlock_tests_enable (deadlock_tests.c:97)
==2537== by 0x10B157: amdgpu_disable_suits (amdgpu_test.c:421)
==2537== by 0x10B157: main (amdgpu_test.c:560)
==2537== Block was alloc'd at
==2537== at 0x4C2CC05: calloc (vg_replace_malloc.c:711)
==2537== by 0x504CA5E: amdgpu_device_initialize (amdgpu_device.c:212)
==2537== by 0x116298: suite_deadlock_tests_enable (deadlock_tests.c:93)
==2537== by 0x10B157: amdgpu_disable_suits (amdgpu_test.c:421)
==2537== by 0x10B157: main (amdgpu_test.c:560)
Reviewed-by: Christian König <christian.koenig@amd.com>
It means it just didn't find an entry for the GPU in the amdgpu.ids file.
Fixes spurious
amdgpu_parse_asic_ids: Cannot parse ASIC IDs: Resource temporarily unavailable
error messages in that case.
Reported-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch adds a complete meson build system, including tests and
install. It has the necessary hooks to allow it be used as a subproject
for other meson based builds such as mesa.
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Chunming Zhou
Bas Nieuwenhuizen
Dylan Baker
Emil Velikov
Eric Engestrom
Rob Clark
Michel Dänzer
Andrey Grodzovsky
Seung-Woo Kim
Christian König
Christoph Haag
Hawking Zhang
Anuj Phogat