- Feb 14, 2019
-
-
Ramalingam C authored
As we have two different patch for commitng the HDCP request 1. DDI_enable (during the modeset) 2. update_pipe (during fastset execution) Currently our kms_content_protection covers only fastset path. So this test adds the coverage for the HDCP during the modeset by performing DPMS off-on and check for HDCP status. But with respect to HDCP we allow few retries from userspace before reporting the failure. So only first attempt at kernel will be on modeset path, next retries will become fastset commiting of HDCP. v2: dpms test is added within existing implementation with a flag [Daniel] v3: ret declared. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ramalingam C authored
Modularizing the CP test steps for the convenience of reusing it for other subtests. Signed-off-by:
-
José Roberto de Souza authored
This tests checks if hardware is able to do selective update when screen changes. PSR2 don't trigger interruptions and the 'PSR2 SU status' register is not kept loaded all the times, so it is necessary keep polling PSR status debugfs until those values are loaded. Also from DEEP_SLEEP state HW will not do a seletive update, as most of the memory/context is lost in deep sleep state hardware will need to exit PSR mode then wait a configured number of frames to activate PSR again to then start doing seletive updates, that is why just one screen change is not enough to pass this tests. When a selective update happens and the values are loaded and read from debugfs it is compared with the expected value of seletive update blocks, if matches the polling is stopped and the test passed otherwise it will wait until it reachs a maximum number o screen changes to fail the test. v2: Using new SU blocks debugfs output v3: - removed the timerfd to fail the test, now failing based in a maximum number of screen changes - removing thread to read debugfs, read from main thread is enough - improved commit message v4: - getting cairo context for frontbuffer test in prepare() - droppoing poll(), using blocking timerfd instead v5: - Doing a modeset before trying to enable PSR2 v6: - doing atomic commits to fix(legacy commit is taking more time in recent kernels causing us to miss the SU when reading debugfs) and speedup test - fixed code to skip test when PSR2 is not possile Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Tested-by:
José Roberto de Souza <jose.souza@intel.com>
-
- Feb 13, 2019
-
-
Easwar Hariharan authored
I spent quite some time trying to install all the dependencies to build igt in for my distribution. After installing the packages, I noticed that the Dockerfiles had the exact packages required for each distribution. Add a pointer to the Dockerfiles in the README to save folks time on setting up the environment required to build igt. CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Easwar Hariharan <easwar.hariharan@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Tomi Valkeinen authored
Add CI for armhf environment. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com>
-
This fixes a compiler warning treated as an error when building for 32-bit architectures since their pointer size does not match the size of drm_i915_gem_context_param.value which is 64 bits: CC i915/gem_ctx_sseu.o i915/gem_ctx_sseu.c: In function ‘test_ggtt_args’: i915/gem_ctx_sseu.c:384:9: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] munmap((void *)arg.value, 4096); It was found while building for arm with gcc 6.3.0 and I suspect the same problem would arise for i386 or other 32-bit architectures. The uintptr_t type is by definition an unsigned integer of the same length as a pointer on a given architecture, so this should fix the problem for all architectures up to 64 bits. Signed-off-by:Guillaume Tucker <guillaume.tucker@collabora.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Arkadiusz Hiler authored
This reverts commit 845c9fb4. To unblock GitLab's CI while a proper solution is in the works. Signed-off-by:
-
As the inline comment says, this test checks that the kernel allows unauthenticated master with render capable, RENDER_ALLOW ioctls. The kernel commit has extra details why. v2: - drop RUN_AS_ROOT guard - call check_auth() on the {,un}authenticated device - check the device is PRIME (import) capable - check the device has render node - tweak expectations based on above three - elaborate why we care only about -EACCES v3: - fold into existing core_auth.c - move igt_assert within the subtest - make has_prime_import() an igt_require() - check for BADF before and after, as requested. Not strictly needed. - swap igt_info+drm_open_driver with comment + __drm_open_driver Former calls igt_skip() which is problematic with igt_fork(). Signed-off-by:Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (irc)
-
Seeming copy/paste from another test. None of the includes are required. Signed-off-by:
-
Maarten Lankhorst authored
The P01x formats are planar 16 bits per component, with the unused lower bits set to 0. This means they can all be converted the same way. Only the range is slightly different, and this is handled in the color_encoding implementation. This requires cairo 1.17.2 and pixman 0.36. This works but doesn't give extra precision. For more than 8 bits precision a few more patches are required to pixman, pending review: https://lists.freedesktop.org/archives/pixman/2019-January/004815.html https://lists.freedesktop.org/archives/pixman/2019-January/004809.html Once those are merged, we will require the next pixman release for better precision. Changes since v1: - Add fallback color definitions when compiling on cairo version < 1.17.2. - Skip when FB creation fails on HDR formats, instead of failing. Changes since v2: - Complain slightly harder when pixman/cairo are out of date. - Create a fb with alpha when converting to pixman formats with alpha. - Oops, s/pixman_format_code_t/cairo_format_t/ Changes since v3: - Rebase on top of upstream YUV changes. Changes since v4: - Rebase again. - Use drm_fourcc.h from drm-misc-next. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v4
-
Maarten Lankhorst authored
We're starting to add support for 10, 12 and 16-bits formats that all have different values for the Y offset and range. Some 10 bits formats go from [0...1023], others go to [0...1023] shifted left by 6. To accomodate all formats add a struct definition for all various formats, this can be extended further when we add new formats. Changes since v1: - Rebase on top of added yuv changes. - Add commit description (swatish) - Add missing newline. (swatish) Signed-off-by:
-
- Feb 12, 2019
-
-
Chris Wilson authored
The first dispatch incurs the cost of waking up the device, so also measure after issuing a spinner to keep the device awake as we submit. Signed-off-by:
Antonio Argenziano <antonio.argenziano@intel.com>
-
Chris Wilson authored
Present the latency results in nanoseconds not RCS cycles. Signed-off-by:
-
Arkadiusz Hiler authored
`ninja test` invokes igt_command_line.sh for each test binary to check the behavior of some of the switches. One of the verified things is that the test exists with non-zero status when requesting invalid subtest. `--run-subtest` results in igt_fixtures being executed - this fiddles with the device and sysfs knobs. Let's exit early, if we are root, to save people form unintentional side-effects and strange failures. Cc: Petri Latvala <petri.latvala@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Signed-off-by:
-
Chris Wilson authored
Only wait a maximum of 2 more seconds for the hang children to complete, to catch deadlocks in a timely fashion. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
- Feb 11, 2019
-
-
Simona Vetter authored
Really not needed if we check this with meson. Acked-by:
Petri Latvala <petri.latvala@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
The NV12, NV16, NV21, NV61, YUV420, YVU420, YUV422 and YVU422 are YUV formats that are currently supported in IGT. We'll want to test those formats in addition to the RGB formats, so let's add some subtests. One thing worth noting is some hardware isn't able to output a pixel-perfect image, so we do the same kind of comparison than for VGA. Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com>
-
The VGA tests were run so far as part of a separate function. However, the only difference between that function and the do_test_display function was the kind of comparison we wanted to use. Indeed, VGA being an analog output, we can't rely on a pixel perfect image, and thus only compare the CRCs, but we need to make some more advanced comparison. Let's add a new check method, add support for the analog check to do_test_display and remove the old version. Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: -
The various tests in kms_chamelium are really variants of one another but share little code. In addition to the duplication, this gets in the way of the introduction of more tests, or to be able to run all the tests on all the output, which isn't the case at the moment, with the HDMI and DP tests and the VGA tests being different. Start by introducing a check parameter to the do_test_display function, that will tell which test method we want to use to compare the frames. Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: -
Thanks to the previous reworks, we can now add new YUV formats pretty easily. This patch adds support for the NV12, NV16, NV21, NV61, YUV420, YVU420, YUV422 and YVU422 formats. Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: -
We only need to allocate a buffer using the GEM API when we're in the condition that we currently test, and that we're running on i915. All the other cases can be handled by a fallback to a dumb buffer allocation. Let's simplify the code a bit to reflect that. Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
-
YUV dumb buffers, just like i915 GEM buffers also need to be cleared once allocated. Make sure it happens. Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: -
The dumb buffer allocation API only considers a single plane, and even though allocating multi-planar buffers through it is allowed, the stride it gives back is the the width times the bpp passed as an argument. That doesn't work in our case, since the bpp is going to be the one we give as an argument, but split over three planes so the stride doesn't match anymore. A proper fix for this would be to have a better dumb buffer allocation API, but for the time being, let's do it that way. Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: -
When allocating a dumb buffer for a format with multiple plane, we need to account for all plane's bpp in order to allocate the proper size. Let's add all the planes bpp and use the result to allocate our buffer. Reviewed-by:
Lyude Paul <lyude@redhat.com> -
Since we want to use the dumb buffers to store frames in formats with multiple planes, we need to add checks for unsupported corner cases, and we need to calculate the offsets and sizes of each planes. Let's use calc_fb_size for that. Signed-off-by:
Lyude Paul <lyude@redhat.com> -
The else condition is not needed, since all the other conditions return when they are done. Move the KMS dumb buffer allocation outside of the outer else condition, this will also allow to ease later changes. Reviewed-by:
Lyude Paul <lyude@redhat.com>
-
- Feb 08, 2019
-
-
Chris Wilson authored
Still the blighted Starting subtest: pi-ringfull-bsd child 0 died with signal 14, Alarm clock Subtest pi-ringfull-bsd: FAIL (0.133s) So let's make sure our timer cannot fire later on during exit. References https://bugs.freedesktop.org/show_bug.cgi?id=109584 Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
Make sure that the SIGARLM handler is captured so that we don't accidentally shoot ourselves in the foot instead of merely waking up the execbuf. The test is hitting child 0 died with signal 14, Alarm clock when we expect it to be hitting the inherited signal handler across the fork. Which is odd. Signed-off-by:
-
- Feb 07, 2019
-
-
Ville Syrjälä authored
On pre-icl we have two registers for the DDB allocations for NV12. Dump the second set of allocations as well. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- Feb 05, 2019
-
-
Ville Syrjälä authored
Replace the old hand rolled platform check funcs with somehting more standard. Signed-off-by:
-
Ville Syrjälä authored
To make it easier to spot errors with watermarks vs. plane being enabled/disabled indicate which planes are actually enabled and which are not. Signed-off-by:
-
Ville Syrjälä authored
Bump up the width of the wm blocks to 11 bits, which it is on icl. On earlier platforms it was actually 10 bits but the code decoded it as 9 bits. Signed-off-by:
-
Ville Syrjälä authored
On icl PLANE_BUF_CFG fields are 11 bits. Decode them correctly. v2: s/biths/bits/ in the subject (José) Signed-off-by:
-
Ville Syrjälä authored
icl has 8 planes per pipe. Bump the limits to match. Signed-off-by:
-
If the VRR tests failed then there was a chance that VRR could be left enabled when exiting the test so the VRR_ENABLED property was reset to 0 whenever the pipe was reset. However, in doing so the pipe's state was considered changed even if VRR_ENABLED was already 0. This causes the pipe to be added to commits where it previously wasn't. Other tests with properties that can persist for failures (like color management) don't bother resetting the properties - so this patch changes VRR_ENABLED to work the same. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490 Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com>
-
Paul Kocialkowski authored
Preliminary patches for the YUV testing series were broken without subsequent patches that fix them when moving things around. The argument provided to clear_yuv_buffer should be the framebuffer, not the DRM file descriptor (fb vs fd). Also, an assert was added to clear_yuv_buffer to ensure that it's only called for YUV formats, which has to be reflected in the calling function. Signed-off-by:
-
The YUV buffer allocation path for the i915 driver also has some code to clear a YUV buffer. As that is going to be useful for all the other drivers, let's move it to a separate function. Reviewed-by:
Lyude Paul <lyude@redhat.com> -
The current way we work when we want to support a new YUV format to IGT, we also need to add new function to convert to and from XRGB8888. This doesn't really scale however, and creates a lot of code to maintain. In order to work around this, create a generic function to convert to RGB and one to convert from RGB. The only thing that is needed now is to add new parameters, and that's it. Reviewed-by:
Lyude Paul <lyude@redhat.com> -
Aligning the width on 64 pixels only make sense on intel platforms, make sure to add a check against this. Reviewed-by:
Lyude Paul <lyude@redhat.com> -
In order to improve the YUV support, let's add the horizontal and vertical subsampling parameters to the IGT formats. Reviewed-by:
Lyude Paul <lyude@redhat.com>
-
