From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Swati Sharma <swati2.sharma@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [v4 3/9] tests/kms_plane_scaling: Upscaling each plane
Date: Tue, 15 Feb 2022 22:43:07 +0200 [thread overview]
Message-ID: <YgwQW7Wjli+6cRZg@intel.com> (raw)
In-Reply-To: <20220215122344.11168-4-swati2.sharma@intel.com>
On Tue, Feb 15, 2022 at 05:53:38PM +0530, Swati Sharma wrote:
> Subtest for testing upscaling for each plane
> individually (checked 1 plane per "class" like
> we do in other tests)
>
> v2: -set modifier as LINEAR (Ville)
> -shared code for upscaling and downscaling tests (Ville)
> -removed num_scaler() check and added try_commit() (Ville)
>
> Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
> ---
> tests/kms_plane_scaling.c | 71 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
> index 1cf62841..39f2de3c 100644
> --- a/tests/kms_plane_scaling.c
> +++ b/tests/kms_plane_scaling.c
> @@ -29,6 +29,11 @@
>
> IGT_TEST_DESCRIPTION("Test display plane scaling");
>
> +/* Test flags. */
> +enum {
> + TEST_UPSCALING = 1 << 0,
> +};
That doesn't seem like it's actually used as flags.
So looks to me like it can be a straight up enum.
> +
> typedef struct {
> uint32_t devid;
> int drm_fd;
> @@ -230,6 +235,65 @@ static bool test_format(data_t *data,
> return true;
> }
>
> +static void
> +__test_plane_upscaling(data_t *d, igt_plane_t *plane,
> + enum pipe pipe, igt_output_t *output)
> +{
> + igt_display_t *display = &d->display;
> + int width, height, ret;
> + drmModeModeInfo *mode;
> +
> + cleanup_crtc(d);
> +
> + igt_output_set_pipe(output, pipe);
> + mode = igt_output_get_mode(output);
> + width = height = 20;
> +
> + igt_create_color_pattern_fb(display->drm_fd,
> + width, height,
> + DRM_FORMAT_XRGB8888,
> + I915_TILING_NONE,
> + 1.0, 0.0, 0.0, &d->fb[0]);
> +
> + igt_plane_set_fb(plane, &d->fb[0]);
> + igt_plane_set_size(plane, mode->hdisplay, mode->vdisplay);
> + ret = igt_display_try_commit_atomic(display, DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);
> + igt_display_commit2(display, COMMIT_ATOMIC);
> +
> + igt_plane_set_fb(plane, NULL);
> + igt_remove_fb(display->drm_fd, &d->fb[0]);
> +
> + igt_skip_on_f(ret == -EINVAL, "Scaling op not supported\n");
So we skip on -EINVAL and pass on anything else (error or success).
Is that going to tell us something useful?
> +}
> +
> +static void
> +test_plane_scaling(data_t *d, enum pipe pipe, igt_output_t *output, uint32_t flags)
> +{
> + igt_display_t *display = &d->display;
> + uint64_t modifier = DRM_FORMAT_MOD_LINEAR;
> + igt_plane_t *plane;
> +
> + for_each_plane_on_pipe(display, pipe, plane) {
> + struct igt_vec tested_formats;
> +
> + if (plane->type == DRM_PLANE_TYPE_CURSOR)
> + continue;
> +
> + igt_vec_init(&tested_formats, sizeof(uint32_t));
> +
> + for (int j = 0; j < plane->drm_plane->count_formats; j++) {
> + uint32_t format = plane->drm_plane->formats[j];
> + if (test_format(d, &tested_formats, format) &&
> + igt_plane_has_format_mod(plane, format, modifier) &&
> + can_scale(d, format))
> + if (flags & TEST_UPSCALING)
I'd probably just have passed a function pointer rather than add that
enum. But maybe it's useful for the other tests...
> + __test_plane_upscaling(d, plane, pipe, output);
> + }
> +
> + igt_vec_fini(&tested_formats);
> + }
> +}
> +
> static bool test_pipe_iteration(data_t *data, enum pipe pipe, int iteration)
> {
> if (!is_i915_device(data->drm_fd) ||
> @@ -547,6 +611,13 @@ igt_main_args("", long_opts, help_str, opt_handler, &data)
> igt_subtest_group {
> igt_output_t *output;
>
> + igt_describe("Tests plane upscaling.");
> + igt_subtest_with_dynamic("plane-upscaling") {
> + for_each_pipe_with_single_output(&data.display, pipe, output)
> + igt_dynamic_f("pipe-%s-%s-upscaling", kmstest_pipe_name(pipe), igt_output_name(output))
> + test_plane_scaling(&data, pipe, output, TEST_UPSCALING);
> + }
> +
> igt_describe("Tests scaling with pixel formats.");
> igt_subtest_with_dynamic("scaler-with-pixel-format") {
> for_each_pipe_with_single_output(&data.display, pipe, output)
> --
> 2.25.1
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-02-15 20:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-15 12:23 [igt-dev] [v4 0/9] Addition of new plane scaling test cases Swati Sharma
2022-02-15 12:23 ` [igt-dev] [v4 1/9] tests/kms_plane_scaling: Removal of plane-scaling subtest Swati Sharma
2022-02-15 12:23 ` [igt-dev] [v4 2/9] tests/kms_plane_scaling: Add output name in dynamic subtests Swati Sharma
2022-02-15 12:23 ` [igt-dev] [v4 3/9] tests/kms_plane_scaling: Upscaling each plane Swati Sharma
2022-02-15 20:43 ` Ville Syrjälä [this message]
2022-02-15 12:23 ` [igt-dev] [v4 4/9] tests/kms_plane_scaling: Downscaling " Swati Sharma
2022-02-15 20:43 ` Ville Syrjälä
[not found] ` <a85c6701-43ad-4b25-6184-8798e8db2e2d@quicinc.com>
2022-02-17 12:15 ` Sharma, Swati2
2022-02-17 18:22 ` Jessica Zhang
2022-02-17 18:37 ` Sharma, Swati2
2022-02-22 19:36 ` Jessica Zhang
2022-02-23 6:46 ` Sharma, Swati2
2022-02-15 12:23 ` [igt-dev] [v4 5/9] tests/kms_plane_scaling: Upscaling on 2 planes Swati Sharma
2022-02-15 20:43 ` Ville Syrjälä
2022-02-15 12:23 ` [igt-dev] [v4 6/9] tests/kms_plane_scaling: Downscaling " Swati Sharma
2022-02-15 12:23 ` [igt-dev] [v4 7/9] tests/kms_plane_scaling: Upscaling and downscaling scenario Swati Sharma
2022-02-15 12:23 ` [igt-dev] [v4 8/9] tests/kms_plane_scaling: Add negative test to check num of scalers Swati Sharma
2022-02-15 12:23 ` [igt-dev] [v4 9/9] tests/kms_plane_scaling: Refactor clipping-clamping subtest Swati Sharma
2022-02-15 18:23 ` [igt-dev] ✓ Fi.CI.BAT: success for Addition of new plane scaling test cases (rev6) Patchwork
2022-02-15 21:59 ` [igt-dev] ✗ Fi.CI.IGT: failure " 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=YgwQW7Wjli+6cRZg@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=swati2.sharma@intel.com \
/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