Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Kunal Joshi <kunal1.joshi@intel.com>, igt-dev@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 01/35] lib/igt_pipe_crc: separate CRTC index from pipe
Date: Mon, 24 Nov 2025 22:55:29 +0200	[thread overview]
Message-ID: <aSTGQa80OSZSiLty@intel.com> (raw)
In-Reply-To: <235aeb5e8949b83daf535586475fe047714458a9@intel.com>

On Mon, Nov 24, 2025 at 10:31:31PM +0200, Jani Nikula wrote:
> On Mon, 24 Nov 2025, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Sun, Nov 23, 2025 at 08:53:38PM +0530, Kunal Joshi wrote:
> >> The pipe CRC helpers have historically treated the logical pipe enum as if it
> >> were the CRTC index, and used that directly in the debugfs paths under
> >> crtc-<index>/crc/. This only works as long as crtc_index == pipe, which is no
> >> longer guaranteed once pipes are virtualized, fused off, or reordered.
> >> 
> >> Introduce an explicit CRTC index in igt_pipe_crc and wire it through the
> >> debugfs control/data paths. Add new constructors that take either a raw CRTC
> >> index or an igt_display+pipe pair, and update kms_pipe_crc_basic to use the
> >> display-aware helper so it always uses display->pipes[pipe].crtc_offset.
> >> 
> >> Keep the existing igt_pipe_crc_new(fd, pipe, ...) API as a thin wrapper that
> >> still assumes crtc_index == pipe for now so existing callers continue to work.
> >> This is a first incremental step towards fully decoupling CRTC indices from
> >> hardware pipes across the KMS tests.
> >> ---
> >>  lib/igt_pipe_crc.c         | 39 +++++++++++++++++++++++++++++++++++---
> >>  lib/igt_pipe_crc.h         |  6 ++++++
> >>  tests/kms_pipe_crc_basic.c | 12 ++++++------
> >>  3 files changed, 48 insertions(+), 9 deletions(-)
> >> 
> >> diff --git a/lib/igt_pipe_crc.c b/lib/igt_pipe_crc.c
> >> index 866bf2881..24aa72bcc 100644
> >> --- a/lib/igt_pipe_crc.c
> >> +++ b/lib/igt_pipe_crc.c
> >> @@ -190,6 +190,8 @@ struct _igt_pipe_crc {
> >>  	int flags;
> >>  
> >>  	enum pipe pipe;
> >
> > This whole pipe thing needs to go away.
> 
> I think there's basically two approaches:
> 
> 1) Just assume pipe == crtc_index everywhere, and single out the cases
>    where the "physical" pipe is actually something else. Use a separate
>    enum for the physical pipe. The downside is that this will continue
>    to confuse and trick people, because the kernel has largely migrated
>    away from this.
> 
> 2) Roll up the sleeves, and call things by their real names. enum pipe
>    needs to mean the physical pipe, and everything else needs to be
>    converted to crtc_index. And where the physical pipe is not needed,
>    which is most places, it needs to be removed. Like here.
> 
> I'm in favour of 2, if the churn it causes is acceptable. Personally I
> think it's worth it to clarify a lot of things all over the place.

Yeah, I think we want as much as possible to just use igt_pipe_t and
rename it to igt_crtc_t. I wrote a bunch of cocci for that as well.
Looks like my current wip branch has about 40 patches or so. That's 
pretty much all pure refactoring. After that things will get harder
and probably will involve manual work to convert most of the tests
to iterate over igt_crtc_t instead of pipes.

> 
> >
> >> +	/* CRTC index in drmModeRes.crtcs used for debugfs paths. */
> >> +	unsigned int crtc_index;
> >>  	char *source;
> >>  };
> >>  
> >> @@ -215,7 +217,8 @@ void igt_require_pipe_crc(int fd)
> >>  }
> >>  
> >>  static igt_pipe_crc_t *
> >> -pipe_crc_new(int fd, enum pipe pipe, const char *source, int flags)
> >> +pipe_crc_new_internal(int fd, enum pipe pipe, unsigned int crtc_index,
> >> +		     const char *source, int flags)
> >>  {
> >>  	igt_pipe_crc_t *pipe_crc;
> >>  	char buf[128];
> >> @@ -235,7 +238,7 @@ pipe_crc_new(int fd, enum pipe pipe, const char *source, int flags)
> >>  	pipe_crc = calloc(1, sizeof(struct _igt_pipe_crc));
> >>  	igt_assert(pipe_crc);
> >>  
> >> -	sprintf(buf, "crtc-%d/crc/control", pipe);
> >> +	sprintf(buf, "crtc-%u/crc/control", crtc_index);
> >>  	pipe_crc->ctl_fd = openat(debugfs, buf, O_WRONLY);
> >>  	igt_assert(pipe_crc->ctl_fd != -1);
> >>  
> >> @@ -243,6 +246,7 @@ pipe_crc_new(int fd, enum pipe pipe, const char *source, int flags)
> >>  	pipe_crc->fd = fd;
> >>  	pipe_crc->dir = debugfs;
> >>  	pipe_crc->pipe = pipe;
> >> +	pipe_crc->crtc_index = crtc_index;
> >>  	pipe_crc->source = strdup(env_source);
> >>  	igt_assert(pipe_crc->source);
> >>  	pipe_crc->flags = flags;
> >> @@ -250,6 +254,15 @@ pipe_crc_new(int fd, enum pipe pipe, const char *source, int flags)
> >>  	return pipe_crc;
> >>  }
> >>  
> >> +static igt_pipe_crc_t *
> >> +pipe_crc_new(int fd, enum pipe pipe, const char *source, int flags)
> >> +{
> >> +	/* Existing callers pass a logical pipe; assume crtc_index == pipe
> >> +	 * until they are converted to use the new helpers.
> >> +	 */
> >> +	return pipe_crc_new_internal(fd, pipe, pipe, source, flags);
> >> +}
> >> +
> >>  /**
> >>   * igt_pipe_crc_new:
> >>   * @fd: fd of the device
> >> @@ -288,6 +301,26 @@ igt_pipe_crc_new_nonblock(int fd, enum pipe pipe, const char *source)
> >>  	return pipe_crc_new(fd, pipe, source, O_RDONLY | O_NONBLOCK);
> >>  }
> >>  
> >> +igt_pipe_crc_t *
> >> +igt_pipe_crc_new_for_crtc(int fd, unsigned int crtc_index,
> >> +			 const char *source)
> >> +{
> >> +	return pipe_crc_new_internal(fd, PIPE_A, crtc_index, source, O_RDONLY);
> >> +}
> >> +
> >> +igt_pipe_crc_t *
> >> +igt_pipe_crc_new_for_display(struct igt_display *display, enum pipe pipe,
> >> +			     const char *source)
> >> +{
> >
> > I think it's better to just pass in the whole igt_pipe_t.
> > In fact I already wrote the cocci for that, but I need to
> > get a bunch of refactroing done in before it can be done.
> > I already posted two small refactoring series, but more
> > will be needed.
> 
> That with the s/igt_pipe_t/igt_crtc_t/ rename would be great.
> 
> There are a few special cases like tools/intel_display_crc.c which
> currently don't have any igt_pipe_t available. But I think the parameter
> for it should anyway be crtc_index not pipe.

Yeah, looks like what I did in my wip branch is s/pipe/crtc_index/
for the current stuff, and then add igt_crtc_crc_new*(igt_crtc_t*, ...)
wrappers around that.

> 
> Hmm, looking at the tool, how does it even work at all? Where does
> ctx.fd come from? I digress.

Looks completely broken to me. Looking at the git log, passing vs. 
not passing the fd to the crc stuff has been applied and reverted
a few times. Personally I just frob the crc debugfs directly
whenever I need to grab CRCs outside of igts, so IMO we could just
nuke the tool.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-11-24 20:55 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-23 15:23 [PATCH i-g-t 00/35] fix pipe-crtc conflict in crc helpers Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 01/35] lib/igt_pipe_crc: separate CRTC index from pipe Kunal Joshi
2025-11-24 19:15   ` Ville Syrjälä
2025-11-24 20:31     ` Jani Nikula
2025-11-24 20:55       ` Ville Syrjälä [this message]
2025-11-25  8:47         ` Joshi, Kunal1
2025-11-23 15:23 ` [PATCH i-g-t 02/35] tests/kms_atomic: use display-aware pipe CRC helper Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 03/35] tests/kms_color: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 04/35] tests/kms_cursor_crc: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 05/35] tests/kms_cursor_legacy: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 06/35] tests/kms_display_modes: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 07/35] tests/kms_hdr: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 08/35] tests/kms_multipipe_modeset: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 09/35] tests/kms_rotation_crc: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 10/35] tests/kms_plane_lowres: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 11/35] tests/kms_async_flips: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 12/35] tests/kms_atomic_transition: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 13/35] tests/kms_plane: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 14/35] tests/kms_plane_alpha_blend, cursor: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 15/35] tests/kms_plane_multiple: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 16/35] tests/kms_sharpness_filter: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 17/35] tests/kms_universal_plane: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 18/35] tests/kms_prime: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 19/35] tests/kms_bw: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 20/35] tests/kms_ccs: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 21/35] tests/kms_fbc_dirty_rect: " Kunal Joshi
2025-11-23 15:23 ` [PATCH i-g-t 22/35] tests/kms_pwrite_crc: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 23/35] tests/xe_pxp: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 24/35] tests/kms_frontbuffer_tracking: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 25/35] tests/kms_mmap_write_crc: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 26/35] tests/kms_dirtyfb: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 27/35] tests/kms_big_fb: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 28/35] tests/xe_pat: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 29/35] tests/kms_draw_crc: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 30/35] tests/kms_fbcon_fbt: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 31/35] tests/tests/intel/kms_flip_scaled_crc: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 32/35] tests/intel/kms_flip_tiling: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 33/35] tests/intel/kms_pipe_stress: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 34/35] tests/intel/kms_fb_coherency: " Kunal Joshi
2025-11-23 15:24 ` [PATCH i-g-t 35/35] tests/intel/gem_pxp: " Kunal Joshi
2025-11-25  5:58 ` ✓ Xe.CI.BAT: success for fix pipe-crtc conflict in crc helpers Patchwork
2025-11-25  6:13 ` ✓ i915.CI.BAT: " Patchwork
2025-11-25  9:14 ` ✗ Xe.CI.Full: failure " Patchwork
2025-11-25 13: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=aSTGQa80OSZSiLty@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=kunal1.joshi@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