| Age | Commit message (Collapse) | Author |
|---|
|
DRM_FORMAT_MOD_LINEAR is the more sensible name for
DRM_FORMAT_MOD_NONE. Use the better name.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
In 22643ce4014a ("Return allocated size in gem_create_in_memory_regions()
and friends") we modified __gem_create_in_memory_regions and
gem_create_in_memory_regions to return the allocated size for buffer
objects. However, this also unnecessarily complicates programming in the
majority of cases where the allocated size is not needed. For example in
several cases it requires tracking the requested and allocated sizes
separately, the size used must be strictly uint64_t etc.
In order to simplify things and provide greater flexibility, here we change
22643ce4014a to follow the same scheme followed in gem_create_ext (and in
gem_create) where __gem_create_ext returns the allocated size but
gem_create_ext doesn't. With this change, __gem_create_in_memory_regions
returns the allocated size for situations where it is needed but in the
majority of cases where the allocated size is not needed we can just use
gem_create_in_memory_regions for casual use as before.
v2: Store requested not allocated bo size in intel_buf->size (Zbigniew)
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
Often the allocated size is of interest and is different from the
requested size. Therefore return allocated size for the object (by
__gem_create_ext()) in gem_create_in_memory_regions() and friends.
v2: Assign buf->size correctly in __intel_buf_init (Zbigniew)
Cc: Andrzej Turko <andrzej.turko@linux.intel.com>
Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
On i915, to avail the dmabuf, the shared object needs to migratable
into smem. So if the shared object is lmem, then it needs to have
smem as second placement option.
Currently kms_prime sharing the dumb buffer between the devices.
But dumb buffer can't have the placements and resides at lmem for the
dgfx. Hence to meet the i915 expectation for dgfx, we create the BO
using the gem_create with smem as second placement option.
v2: Used gem_mmap__device_coherent for mmaped ptr (Ashutosh)
v3: dumb buffer ioctls are used for non i915 drivers
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> (v2)
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
|
|
kms_prime uses vgem driver for fb creation which does not
take care of intel's 64B align requirement. As we want to
keep vgem driver clean we are doing align requirement in
kms_prime test itself.
Also having different alignment requirement by different drivers,
256B aligned should work for all drm drivers.
amdgpu and radeon, amdgpu_align_pitch: 256B
armada, armada_pitch: 128B
exynos_drm_gem_dumb_create: No alignment required
drm_gem_shmem_dumb_create: 8B
drm_gem_vram_fill_create_dumb: 8B
Thus 256B covers everything we see in the kernel drm drivers.
Changes since V2:
- Edited commit message to give more detailed info about patch requirement - zkempczy/Daniel
Changes since V1:
- Edited commit message with driver compatible with 256B align - Daniel
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
Use the definition from kernel headers.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
The test now uses dumb buffers explicitly instead of the vgem helpers.
By default the first two devices that are matching provided chipset requirements
are used (ANY + VGEM). This is sensitive to enumeration order, but as long as
there are only two devices it's fine - PRIME will get tested both directions.
IGT-Version: 1.25-g0b58fd8c (x86_64) (Linux: 5.7.0-rc2-CI-CI_DRM_8370+ x86_64)
Starting subtest: basic-crc
Starting dynamic subtest: first-to-second
Test requirement not met in function igt_require_pipe_crc, file ../lib/igt_debugfs.c:522:
Test requirement: fstatat(dir, "crtc-0/crc/control", &stat, 0) == 0
CRCs not supported on this platform
Last errno: 2, No such file or directory
Dynamic subtest first-to-second: SKIP (0,000s)
Starting dynamic subtest: second-to-first
Dynamic subtest second-to-first: SUCCESS (1,779s)
Subtest basic-crc: SUCCESS (2,024s)
In case there are more than two devices you can specify which ones should be
used or force ordering, e.g.:
sys:/sys/devices/pci0000:00/0000:00:02.0
subsystem : pci
drm card : /dev/dri/card0
drm render : /dev/dri/renderD128
vendor : 8086
device : 9A49
sys:/sys/devices/platform/vgem
subsystem : platform
drm card : /dev/dri/card1
drm render : /dev/dri/renderD129
IGT-Version: 1.25-g0b58fd8c (x86_64) (Linux: 5.7.0-rc2-CI-CI_DRM_8370+ x86_64)
Starting subtest: basic-crc
Looking for devices to open using filter 0: sys:/sys/devices/platform/vgem
Filter matched /dev/dri/card1 | /dev/dri/renderD129
Looking for devices to open using filter 1: pci:vendor=Intel
Filter matched /dev/dri/card0 | /dev/dri/renderD128
Starting dynamic subtest: first-to-second
Dynamic subtest first-to-second: SUCCESS (1,978s)
Starting dynamic subtest: second-to-first
Test requirement not met in function igt_require_pipe_crc, file ../lib/igt_debugfs.c:522:
Test requirement: fstatat(dir, "crtc-0/crc/control", &stat, 0) == 0
CRCs not supported on this platform
Last errno: 2, No such file or directory
Dynamic subtest second-to-first: SKIP (0,000s)
Subtest basic-crc: SUCCESS (2,944s)
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Fix compiler warning about
../tests/kms_prime.c: In function ‘setup_display’:
../tests/kms_prime.c:74:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
igt_output_t *output = igt_get_single_output_for_pipe(display, pipe);
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Currently, there are different sets of prime tests:
- vgem + i915
- amdgpu + i915
- nouveau + i915
The idea is to create a set of tests which are expected to work on any
prime-compatible driver. It can be run with any combination of
exporter + importer, while those devices have respective prime
capabilities. In order to be vendor-agnostic, tests should use generic
KMS API.
Since vgem can be used as both exporter and importer, and there aren't
any generic kms features which vgem doesn't support, it is sufficient
to test vgem as exporter with any other KMS driver.
The first test is simple:
1. Exporter creates a dumb FB and fills it with a plain color
2. FB is transferred to the importer
3. Importer modesets and computes pipe CRC
4. Importer draws the same color through cairo and compares CRC
The initial motivation comes from the need to test prime support in
vkms.
V2:
- Chris: rename the file
- Simon: memory hygiene, codestyle
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Simon Ser <simon.ser@intel.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Simon Ser <daniel@ffwll.ch>
Signed-off-by: Oleg Vasilev <oleg.vasilev@intel.com>
|
