From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
"Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
Subject: Re: [PATCH i-g-t v2 9/9] tests/intel/xe_pxp: Test encrypted FBs
Date: Fri, 31 Jan 2025 01:47:23 +0000 [thread overview]
Message-ID: <05f3087128a9840ee57dc3657910424755d46841.camel@intel.com> (raw)
In-Reply-To: <20250116001951.4159243-10-daniele.ceraolospurio@intel.com>
LGTM - similiar flow to the i915's version (which is expected since i915 and Xe
both are KMS based implementations on the display side of things).
Appreciate the render-copy taking src from the reference FB (as opposed to a temp
buffer that just happens to be initialized to the same color unlike the i915 way).
I have one feedback on abstracting some repeating sequence into a helper,
but given its minimal value, I consider that a nit. Thus:
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
On Wed, 2025-01-15 at 16:19 -0800, Daniele Ceraolo Spurio wrote:
> PXP allows a user to send an encrypted BO to the display HW without
> having to decode it. The driver needs however to tell the HW that the
> BO is encrypted, otherwise it won't be displayed correctly. Furthermore,
> if PXP is terminated before the FB is displayed, we expect to see a black
> screen instead of what's in the BO.
>
>
alan:snip
> +static void test_display_pxp_fb(int fd, igt_display_t *display)
> +{
> + igt_output_t *output;
> + drmModeModeInfo *mode;
> + igt_fb_t ref_fb, pxp_fb;
> + igt_plane_t *plane;
> + igt_pipe_t *pipe;
> + int width = 0, height = 0, i = 0;
> + uint32_t q;
> + uint32_t vm;
> +
> + vm = xe_vm_create(fd, 0, 0);
> + q = create_pxp_rcs_queue(fd, vm); /* start the PXP session */
> +
> + for_each_connected_output(display, output) {
> + mode = igt_output_get_mode(output);
> +
> + width = max_t(int, width, mode->hdisplay);
> + height = max_t(int, height, mode->vdisplay);
> + }
> +
> + igt_create_color_fb(fd, width, height, DRM_FORMAT_XRGB8888, DRM_FORMAT_MOD_LINEAR,
> + 0, 1, 0, &ref_fb);
> +
> + /* Do a modeset on all outputs */
> + for_each_connected_output(display, output) {
> + mode = igt_output_get_mode(output);
> + pipe = &display->pipes[i];
> + plane = igt_pipe_get_plane_type(pipe, DRM_PLANE_TYPE_PRIMARY);
> + igt_require(igt_pipe_connector_valid(i, output));
> + igt_output_set_pipe(output, i);
> +
> + igt_plane_set_fb(plane, &ref_fb);
> + igt_fb_set_size(&ref_fb, plane, mode->hdisplay, mode->vdisplay);
> + igt_plane_set_size(plane, mode->hdisplay, mode->vdisplay);
> +
> + igt_display_commit2(display, COMMIT_ATOMIC);
alan: nit: I see an opportunity for optimization by adding a local helper for the following sequence of KMS calls that
seems to be replicated 3 times for this test:
igt_plane_set_fb(plane, fb);
igt_fb_set_size(fb, plane, height, width);
igt_plane_set_size(plane, height, width);
igt_display_commit2(display, COMMIT_ATOMIC);
> + i++;
> + }
> +
> + /* Create an encrypted FB with the same contents as ref_fb */
> + setup_protected_fb_from_ref(fd, &ref_fb, &pxp_fb, q, vm);
> +
> + /* Flip both FBs and make sure the CRCs match */
> + compare_crcs(fd, display, &ref_fb, &pxp_fb);
> +
> + igt_remove_fb(fd, &ref_fb);
> + igt_remove_fb(fd, &pxp_fb);
> + xe_exec_queue_destroy(fd, q);
> + xe_vm_destroy(fd, vm);
> +}
> +
> +/**
> + * SUBTEST: display-black-pxp-fb
> + * Description: Test that an invalid encrypted fb is correctly converted to a
> + * black screen by comparing its CRCs with the ones generated by a
> + * non-encrypted FB filled with black
> + */
> +
> +static void test_display_black_pxp_fb(int fd, igt_display_t *display)
alan:snip
next prev parent reply other threads:[~2025-01-31 1:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 0:19 [PATCH i-g-t v2 0/9] Xe: Add tests for PXP Daniele Ceraolo Spurio
2025-01-16 0:19 ` [PATCH i-g-t v2 1/9] drm-uapi/xe: Sync PXP uapi updates Daniele Ceraolo Spurio
2025-01-16 0:19 ` [PATCH i-g-t v2 2/9] tests/intel/xe_vm: Update invalid flag subtest Daniele Ceraolo Spurio
2025-01-16 21:55 ` Teres Alexis, Alan Previn
2025-01-16 0:19 ` [PATCH i-g-t v2 3/9] tests/intel/xe_query: Add test for PXP status query Daniele Ceraolo Spurio
2025-01-16 0:19 ` [PATCH i-g-t v2 4/9] tests/intel/xe_create: Stop treating the extension field as MBZ Daniele Ceraolo Spurio
2025-01-16 22:02 ` Teres Alexis, Alan Previn
2025-01-16 0:19 ` [PATCH i-g-t v2 5/9] tests/intel/xe_exec_queue_property: Update first invalid property value Daniele Ceraolo Spurio
2025-01-16 22:06 ` Teres Alexis, Alan Previn
2025-01-16 0:19 ` [PATCH i-g-t v2 6/9] tests/intel/xe_pxp: Add PXP object and queue creation tests Daniele Ceraolo Spurio
2025-01-16 22:16 ` Teres Alexis, Alan Previn
2025-01-16 0:19 ` [PATCH i-g-t v2 7/9] tests/intel/xe_pxp: Test PXP submissions Daniele Ceraolo Spurio
2025-01-28 2:44 ` Teres Alexis, Alan Previn
2025-01-16 0:19 ` [PATCH i-g-t v2 8/9] tests/intel/xe_pxp: Termination tests Daniele Ceraolo Spurio
2025-01-28 5:13 ` Teres Alexis, Alan Previn
2025-01-16 0:19 ` [PATCH i-g-t v2 9/9] tests/intel/xe_pxp: Test encrypted FBs Daniele Ceraolo Spurio
2025-01-31 1:47 ` Teres Alexis, Alan Previn [this message]
2025-01-16 4:55 ` ✓ Xe.CI.BAT: success for Xe: Add tests for PXP (rev2) Patchwork
2025-01-16 4:56 ` ✓ i915.CI.BAT: " Patchwork
2025-01-16 9:38 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-17 10:03 ` ✗ i915.CI.Full: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=05f3087128a9840ee57dc3657910424755d46841.camel@intel.com \
--to=alan.previn.teres.alexis@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=igt-dev@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox