Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/i915: Use intel_de_read64_2x32_volatile_fw() for IVB_TIMESTAMP_CTR+PIPE_FRMTMSTMP query
Date: Thu, 22 Oct 2026 15:10:12 +0300	[thread overview]
Message-ID: <81225a55c325cee43a4e8de745276317873ea8f1@intel.com> (raw)
In-Reply-To: <20261022115548.32678-2-ville.syrjala@linux.intel.com>

On Thu, 22 Oct 2026, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Switch the combined IVB_TIMESTAMP_CTR+PIPE_FRMTMSTMP read to
> use intel_de_read64_2x32_volatile_fw(). It basically does the
> same thing that we were doing by hand, and both are already
> using the intel_de_read_fw().
>
> This has a few functional changes:
> - intel_de_read64_2x32_volatile_fw() has a retry limit, the
>   old code did not

This change is probably a good thing?

Reviewed-by: Jani Nikula <jani.nikula@intel.com>


> - when retrying intel_de_read64_2x32_volatile_fw() reads each
>   register once, the old code always read PIPE_FRMTMSTMP twice
>   and IVB_TIMESTAMP_CTR once
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_vblank.c | 34 +++++++--------------
>  1 file changed, 11 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c
> index 99cb648cab73..1d4753605675 100644
> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> @@ -142,34 +142,22 @@ static u32 intel_crtc_scanlines_since_frame_timestamp(struct intel_crtc *crtc)
>  	const struct drm_display_mode *mode = &vblank->hwmode;
>  	u32 htotal = mode->crtc_htotal;
>  	u32 clock = mode->crtc_clock;
> -	u32 scan_prev_time, scan_curr_time, scan_post_time;
> +	u32 curr_time, frame_time;
> +	u64 result;
>  
>  	/*
> -	 * To avoid the race condition where we might cross into the
> -	 * next vblank just between the PIPE_FRMTMSTMP and TIMESTAMP_CTR
> -	 * reads. We make sure we read PIPE_FRMTMSTMP and TIMESTAMP_CTR
> -	 * during the same frame.
> +	 * IVB_TIMESTAMP_CTR is the current timestamp, PIPE_FRMTMSTMP
> +	 * is the sampled timestamp at the start of the previous
> +	 * delayed vblank. intel_de_read64_2x32_volatile_fw() gives
> +	 * a race free snapshot of both registers.
>  	 */
> -	do {
> -		/*
> -		 * This field provides read back of the display
> -		 * pipe frame time stamp. The time stamp value
> -		 * is sampled at every start of vertical blank.
> -		 */
> -		scan_prev_time = intel_de_read_fw(display,
> +	result = intel_de_read64_2x32_volatile_fw(display,
> +						  IVB_TIMESTAMP_CTR,
>  						  PIPE_FRMTMSTMP(crtc->pipe));
> +	curr_time = lower_32_bits(result);
> +	frame_time = upper_32_bits(result);
>  
> -		/*
> -		 * The TIMESTAMP_CTR register has the current
> -		 * time stamp value.
> -		 */
> -		scan_curr_time = intel_de_read_fw(display, IVB_TIMESTAMP_CTR);
> -
> -		scan_post_time = intel_de_read_fw(display,
> -						  PIPE_FRMTMSTMP(crtc->pipe));
> -	} while (scan_post_time != scan_prev_time);
> -
> -	return div_u64(mul_u32_u32(scan_curr_time - scan_prev_time,
> +	return div_u64(mul_u32_u32(curr_time - frame_time,
>  				   clock), 1000 * htotal);
>  }

-- 
Jani Nikula, Intel

  reply	other threads:[~2026-10-22 12:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 11:55 [PATCH 0/4] drm/i915: Optimize registers accesses in irq handlers Ville Syrjala
2026-10-22 11:55 ` [PATCH 1/4] drm/i915: Use intel_de_read64_2x32_volatile_fw() for IVB_TIMESTAMP_CTR+PIPE_FRMTMSTMP query Ville Syrjala
2026-10-22 12:10   ` Jani Nikula [this message]
2026-10-22 11:55 ` [PATCH 2/4] drm/i915: Use intel_de_{read, write})fw() in BDW+ irq handlers Ville Syrjala
2026-10-22 12:29   ` Jani Nikula
2026-10-22 11:55 ` [PATCH 3/4] drm/i915: Use intel_de_{read, write})fw() in VLV/CHV " Ville Syrjala
2026-10-22 12:31   ` Jani Nikula
2026-10-22 11:55 ` [PATCH 4/4] drm/i915: Skip redundant frame/scanline/time reads for async flips Ville Syrjala
2026-10-22 12:15   ` Jani Nikula
2026-10-22 12:02 ` ✗ CI.checkpatch: warning for drm/i915: Optimize registers accesses in irq handlers Patchwork
2026-10-22 12:05 ` ✓ CI.KUnit: success " Patchwork
2026-10-22 12:41 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-10-22 19:28 ` ✗ Xe.CI.FULL: " Patchwork
2026-10-23 18:20 ` ✗ CI.checkpatch: warning for drm/i915: Optimize registers accesses in irq handlers (rev2) Patchwork
2026-10-23 18:23 ` ✓ CI.KUnit: success " Patchwork
2026-10-23 19:00 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-24  2:08 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-10-28 11:04   ` Saarinen, Jani

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=81225a55c325cee43a4e8de745276317873ea8f1@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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