public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 4/5] tests/kms_multipipe_modeset: use igt_next_crtc()
Date: Fri, 6 Mar 2026 16:04:05 +0200	[thread overview]
Message-ID: <aare1TykX5nruyn7@intel.com> (raw)
In-Reply-To: <7d66e7bd76f0a7b1caf2274eaf870c483ed75ae7.1772803372.git.jani.nikula@intel.com>

On Fri, Mar 06, 2026 at 03:23:57PM +0200, Jani Nikula wrote:
> The test doesn't care about pipes, but rather just another CRTC, so
> prefer igt_next_crtc() over looping pipes and igt_crtc_for_pipe().
> 
> It's all a bit subtle, but previously the test depended on consecutive
> pipes. Using CRTC indices allows for fused off pipes in between.
> 
> While at it, prefer CRTC nomenclature in the variables and messages.
> 
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  tests/kms_multipipe_modeset.c | 32 ++++++++++++++------------------
>  1 file changed, 14 insertions(+), 18 deletions(-)
> 
> diff --git a/tests/kms_multipipe_modeset.c b/tests/kms_multipipe_modeset.c
> index 1980a0c61116..3c10bb1bd5fe 100644
> --- a/tests/kms_multipipe_modeset.c
> +++ b/tests/kms_multipipe_modeset.c
> @@ -48,17 +48,16 @@ typedef struct {
>  	struct igt_fb fb;
>  } data_t;
>  
> -static void run_test(data_t *data, int valid_outputs)
> +static void run_test(data_t *data)
>  {
>  	igt_output_t *output;
>  	igt_pipe_crc_t *pipe_crcs[IGT_MAX_PIPES] = { 0 };
>  	igt_crc_t ref_crcs[IGT_MAX_PIPES], new_crcs[IGT_MAX_PIPES];
>  	igt_display_t *display = &data->display;
>  	uint16_t width = 0, height = 0;
> -	igt_crtc_t *crtc;
> +	igt_crtc_t *crtc = NULL;
>  	igt_plane_t *plane;
>  	drmModeModeInfo *mode;
> -	int i = 0;
>  
>  	for_each_connected_output(display, output) {
>  		mode = igt_output_get_mode(output);
> @@ -75,13 +74,12 @@ static void run_test(data_t *data, int valid_outputs)
>  
>  	/* Collect reference CRC by Committing individually on all outputs*/
>  	for_each_connected_output(display, output) {
> -		crtc = igt_crtc_for_pipe(display, i);
> +		crtc = igt_next_crtc(display, crtc);
>  		plane = igt_crtc_get_plane_type(crtc, DRM_PLANE_TYPE_PRIMARY);
>  
>  		mode = NULL;
>  
> -		pipe_crcs[i] = igt_crtc_crc_new(crtc,
> -						IGT_PIPE_CRC_SOURCE_AUTO);
> +		pipe_crcs[crtc->crtc_index] = igt_crtc_crc_new(crtc, IGT_PIPE_CRC_SOURCE_AUTO);
>  
>  		igt_output_set_crtc(output,
>  				    crtc);
> @@ -93,15 +91,14 @@ static void run_test(data_t *data, int valid_outputs)
>  		igt_plane_set_size(plane, mode->hdisplay, mode->vdisplay);
>  
>  		igt_display_commit2(display, COMMIT_ATOMIC);
> -		igt_pipe_crc_collect_crc(pipe_crcs[i], &ref_crcs[i]);
> +		igt_pipe_crc_collect_crc(pipe_crcs[crtc->crtc_index], &ref_crcs[crtc->crtc_index]);
>  		igt_output_set_crtc(output, NULL);
> -		i++;
>  	}
>  
> -	i = 0;
>  	/* Simultaneously commit on all outputs */
> +	crtc = NULL;
>  	for_each_connected_output(display, output) {
> -		crtc = igt_crtc_for_pipe(display, i);
> +		crtc = igt_next_crtc(display, crtc);
>  		plane = igt_crtc_get_plane_type(crtc, DRM_PLANE_TYPE_PRIMARY);
>  
>  		mode = NULL;
> @@ -114,22 +111,21 @@ static void run_test(data_t *data, int valid_outputs)
>  		igt_plane_set_fb(plane, &data->fb);
>  		igt_fb_set_size(&data->fb, plane, mode->hdisplay, mode->vdisplay);
>  		igt_plane_set_size(plane, mode->hdisplay, mode->vdisplay);
> -		i++;
>  	}
>  
>  	igt_display_commit2(display, COMMIT_ATOMIC);
>  
>  	/* CRC Verification */
> -	for (i = 0; i < valid_outputs; i++) {
> -		igt_pipe_crc_collect_crc(pipe_crcs[i], &new_crcs[i]);
> -		igt_assert_crc_equal(&ref_crcs[i], &new_crcs[i]);
> +	for_each_crtc(display, crtc) {
> +		igt_pipe_crc_collect_crc(pipe_crcs[crtc->crtc_index], &new_crcs[crtc->crtc_index]);
> +		igt_assert_crc_equal(&ref_crcs[crtc->crtc_index], &new_crcs[crtc->crtc_index]);

We may not have used up all the CRTCs since we only picked one for
each connected output. So this would need some kind of pipe_crcs[...]==NULL
check perhaps.

>  	}
>  
>  	igt_plane_set_fb(plane, NULL);
>  	igt_remove_fb(data->drm_fd, &data->fb);
>  }
>  
> -static void test_multipipe(data_t *data, int num_pipes)
> +static void test_multipipe(data_t *data, int num_crtcs)
>  {
>  	igt_output_t *output;
>  	int valid_outputs = 0;
> @@ -137,11 +133,11 @@ static void test_multipipe(data_t *data, int num_pipes)
>  	for_each_connected_output(&data->display, output)
>  		valid_outputs++;
>  
> -	igt_require_f(valid_outputs == num_pipes,
> +	igt_require_f(valid_outputs == num_crtcs,
>  		      "Number of connected outputs(%d) not equal to the "
> -		      "number of pipes supported(%d)\n", valid_outputs, num_pipes);
> +		      "number of CRTCs supported(%d)\n", valid_outputs, num_crtcs);

Oh, apparently we do check that we have the same number of outputs and
CRTCs. That makes no sense to me. Apparently the original intention was
to make sure all CRTCs can be lit up simultaneously. For that we should
only care about having at least as many outputs as CRTCs.

Or more correctly we should make sure we have valid output for each
CRTC, which given potential CRTC<->output routing constraints isn't
even the same thing as just comparing the numbers. So it should probably
use something like for_each_crtc_with_single_output(), and then make
sure it actually found a valid output for every CRTC.

But given the already poor state of the test, this patch doesn't 
seem to make it any worse so
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

I guess the other thing to consider is whether this test makes
any sense at all. I'm not sure what specifically lighting up all
the CRTCs is supposed to achieve vs. just lighting up some of them...

>  
> -	run_test(data, valid_outputs);
> +	run_test(data);
>  }
>  
>  int igt_main()
> -- 
> 2.47.3

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2026-03-06 14:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-06 13:23 [PATCH i-g-t 0/5] igt: reduce igt_crtc_for_pipe() usage Jani Nikula
2026-03-06 13:23 ` [PATCH i-g-t 1/5] lib/kms: add igt_next_crtc() Jani Nikula
2026-03-06 13:23 ` [PATCH i-g-t 2/5] tests/intel/gem_pxp: use igt_next_crtc() Jani Nikula
2026-03-06 13:23 ` [PATCH i-g-t 3/5] tests/intel/xe_pxp: " Jani Nikula
2026-03-06 13:23 ` [PATCH i-g-t 4/5] tests/kms_multipipe_modeset: " Jani Nikula
2026-03-06 14:04   ` Ville Syrjälä [this message]
2026-03-09  9:27     ` Jani Nikula
2026-03-06 13:23 ` [PATCH i-g-t 5/5] lib/kms: add igt_random_crtc() and use it in gem_eio Jani Nikula
2026-03-06 14:07 ` [PATCH i-g-t 0/5] igt: reduce igt_crtc_for_pipe() usage Ville Syrjälä
2026-03-06 14:59 ` ✓ i915.CI.BAT: success for " Patchwork
2026-03-06 15:04 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-07 16:08 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-03-07 16:12 ` ✗ 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=aare1TykX5nruyn7@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jani.nikula@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