From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 11/16] drm/i915/vblank: Add helper to get correct vblank length
Date: Tue, 7 Oct 2025 18:16:57 +0300 [thread overview]
Message-ID: <aOUu6WoGHhYv4mRy@intel.com> (raw)
In-Reply-To: <f1a8c1bc-6977-4ba4-9ffc-b1a4922d3f43@intel.com>
On Tue, Oct 07, 2025 at 11:22:44AM +0530, Nautiyal, Ankit K wrote:
>
> On 10/7/2025 1:26 AM, Ville Syrjälä wrote:
> > On Mon, Oct 06, 2025 at 09:58:47AM +0530, Ankit Nautiyal wrote:
> >> Currently crtc_vblank_start is assumed to be the vblank_start for the fixed
> >> refresh rate case. That value can be different from the variable refresh
> >> rate case whenever always_use_vrr_tg()==false. On icl/tgl it's always
> >> different due to the extra vblank delay, and also on adl+ it could be
> >> different if we were to use an optimized guardband.
> >>
> >> So places where crtc_vblank_start is used to compute vblank length needs
> >> change so as to account for cases where vrr is enabled. Specifically
> >> with vrr.enable the effective vblank length is actually guardband.
> >>
> >> Add a helper to get the correct vblank length for both vrr and fixed
> >> refresh rate cases. Use this helper where vblank_start is used to
> >> compute the vblank length.
> >>
> >> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >> ---
> >> drivers/gpu/drm/i915/display/intel_pfit.c | 11 +++++++----
> >> drivers/gpu/drm/i915/display/intel_psr.c | 3 +--
> >> drivers/gpu/drm/i915/display/intel_vblank.c | 10 ++++++++++
> >> drivers/gpu/drm/i915/display/intel_vblank.h | 2 ++
> >> drivers/gpu/drm/i915/display/skl_watermark.c | 3 ++-
> >> 5 files changed, 22 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_pfit.c b/drivers/gpu/drm/i915/display/intel_pfit.c
> >> index 68539e7c2a24..ebbaa1d419ba 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_pfit.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_pfit.c
> >> @@ -14,6 +14,7 @@
> >> #include "intel_lvds_regs.h"
> >> #include "intel_pfit.h"
> >> #include "intel_pfit_regs.h"
> >> +#include "intel_vblank.h"
> >> #include "skl_scaler.h"
> >>
> >> static int intel_pch_pfit_check_dst_window(const struct intel_crtc_state *crtc_state)
> >> @@ -306,14 +307,15 @@ centre_horizontally(struct drm_display_mode *adjusted_mode,
> >> }
> >>
> >> static void
> >> -centre_vertically(struct drm_display_mode *adjusted_mode,
> >> +centre_vertically(struct intel_crtc_state *crtc_state,
> >> + struct drm_display_mode *adjusted_mode,
> >> int height)
> >> {
> >> u32 border, sync_pos, blank_width, sync_width;
> >>
> >> /* keep the vsync and vblank widths constant */
> >> sync_width = adjusted_mode->crtc_vsync_end - adjusted_mode->crtc_vsync_start;
> >> - blank_width = adjusted_mode->crtc_vblank_end - adjusted_mode->crtc_vblank_start;
> >> + blank_width = intel_crtc_vblank_length(crtc_state);
> > This pfit stuff is computed way before the guardband, and also only
> > relevant for ancient gen2-4 hardware. So no point in touching this
> > stuff IMO.
>
> Alright can skip this stuff.
>
>
> >
> >> sync_pos = (blank_width - sync_width + 1) / 2;
> >>
> >> border = (adjusted_mode->crtc_vdisplay - height + 1) / 2;
> >> @@ -392,7 +394,8 @@ static void i9xx_scale_aspect(struct intel_crtc_state *crtc_state,
> >> PFIT_HORIZ_INTERP_BILINEAR);
> >> }
> >> } else if (scaled_width < scaled_height) { /* letter */
> >> - centre_vertically(adjusted_mode,
> >> + centre_vertically(crtc_state,
> >> + adjusted_mode,
> >> scaled_width / pipe_src_w);
> >>
> >> *border = LVDS_BORDER_ENABLE;
> >> @@ -489,7 +492,7 @@ static int gmch_panel_fitting(struct intel_crtc_state *crtc_state,
> >> * heights and modify the values programmed into the CRTC.
> >> */
> >> centre_horizontally(adjusted_mode, pipe_src_w);
> >> - centre_vertically(adjusted_mode, pipe_src_h);
> >> + centre_vertically(crtc_state, adjusted_mode, pipe_src_h);
> >> border = LVDS_BORDER_ENABLE;
> >> break;
> >> case DRM_MODE_SCALE_ASPECT:
> >> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
> >> index f7115969b4c5..ae6b94a5d450 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> >> @@ -1365,8 +1365,7 @@ static bool wake_lines_fit_into_vblank(struct intel_dp *intel_dp,
> >> bool aux_less)
> >> {
> >> struct intel_display *display = to_intel_display(intel_dp);
> >> - int vblank = crtc_state->hw.adjusted_mode.crtc_vblank_end -
> >> - crtc_state->hw.adjusted_mode.crtc_vblank_start;
> >> + int vblank = intel_crtc_vblank_length(crtc_state);
> > I *think* this also gets computed during .compute_config() which is
> > before the guardband calculation. So if this stuff actually depends on
> > the guardband then we have a real problem here. And if it doesn't (as
> > in it really interested in the undelayed vblank length) them maybe it
> > should just compute it as crtc_vtotal-crtc_vactive.
>
> As far as I understand it depends on guardband for VRR case.
> For non vrr case : crtc_vtotal - crtc_vactive - scl lines
> For vrr case: guardband length.
>
> Currently since guardband is equal to vblank length this can be
> crtc_vtotal - crtc_vactive - scl lines.
>
> Perhaps with the optimized guardband, we need to set the guardband
> during intel_vrr_compute_config().
>
> Later intel_psr_compute_config gets called and then we can check the
> guardband.
Originally we moved the vblank delay calculation to happen later
because we needed to know about PSR for it to be done correctly.
I think someone will need to try to actually write down all the
requirements from both PSR and VRR side and sides and come up
with a way to get it all done in the right order, without any
more chicken vs. egg problems.
>
>
> >
> >> int wake_lines;
> >>
> >> if (aux_less)
> >> diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c
> >> index 0b7fcc05e64c..2fc0c1c0bb87 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> >> @@ -767,3 +767,13 @@ int intel_vblank_evade(struct intel_vblank_evade_ctx *evade)
> >>
> >> return scanline;
> >> }
> >> +
> >> +int intel_crtc_vblank_length(const struct intel_crtc_state *crtc_state)
> >> +{
> >> + const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> >> +
> >> + if (crtc_state->vrr.enable)
> >> + return crtc_state->vrr.guardband;
> >> + else
> >> + return adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vblank_start;
> > Maybe that should be crtc_vblank_end instead of crtc_vtotal? I guess it
> > doesn't actually matter given where this gets used.
>
> We can use Vblank end.
>
> Apart from these places, do you think there are more places where
> vblank_start adjustement is required?
> For evasion logic and wait for push in case of VRR, we are already using
> vmin_vtotal - guardband to get the delayed vblank start so we are covered.
>
> Regards,
>
> Ankit
>
> >
> > I think the only case where vblank_end!=vtotal is exactly than ancient
> > gen2-4 pfit centering stuff. But I've never actually investigated
> > whether the exact value of vblank_end there even matters. I should do
> > that one day...
> >
> >> +}
> >> diff --git a/drivers/gpu/drm/i915/display/intel_vblank.h b/drivers/gpu/drm/i915/display/intel_vblank.h
> >> index 21fbb08d61d5..98d04cacd65f 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_vblank.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_vblank.h
> >> @@ -48,4 +48,6 @@ const struct intel_crtc_state *
> >> intel_pre_commit_crtc_state(struct intel_atomic_state *state,
> >> struct intel_crtc *crtc);
> >>
> >> +int intel_crtc_vblank_length(const struct intel_crtc_state *crtc_state);
> >> +
> >> #endif /* __INTEL_VBLANK_H__ */
> >> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c b/drivers/gpu/drm/i915/display/skl_watermark.c
> >> index 73e5b2d8ae83..6fb2c78fe29b 100644
> >> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> >> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> >> @@ -28,6 +28,7 @@
> >> #include "intel_flipq.h"
> >> #include "intel_pcode.h"
> >> #include "intel_plane.h"
> >> +#include "intel_vblank.h"
> >> #include "intel_wm.h"
> >> #include "skl_universal_plane_regs.h"
> >> #include "skl_scaler.h"
> >> @@ -2171,7 +2172,7 @@ skl_is_vblank_too_short(const struct intel_crtc_state *crtc_state,
> >> return crtc_state->framestart_delay +
> >> intel_usecs_to_scanlines(adjusted_mode, latency) +
> >> wm0_lines >
> >> - adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vblank_start;
> >> + intel_crtc_vblank_length(crtc_state);
> >> }
> >>
> >> int skl_max_wm0_lines(const struct intel_crtc_state *crtc_state)
> >> --
> >> 2.45.2
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-10-07 15:17 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 4:28 [PATCH 00/16] Optimize vrr.guardband and fix LRR Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 01/16] drm/i915/vrr: Use crtc_vsync_start/end for computing vrr.vsync_start/end Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 02/16] drm/i915/skl_watermark: Fix the scaling factor for chroma subsampling Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 03/16] drm/i915/skl_watermark: Pass linetime as argument to latency helpers Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 04/16] drm/i915/skl_scaler: Introduce helper for chroma downscale factor Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 05/16] drm/i915/display: Extract helpers to set dsc/scaler prefill latencies Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 06/16] drm/i915/dp: Add SDP latency computation helper Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 07/16] drm/i915/alpm: Add function to compute max link-wake latency Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 08/16] drm/i915/display: Add guardband check for feature latencies Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 09/16] drm/i915/skl_watermark: Remove redundant latency checks from vblank validation Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 10/16] drm/i915/vrr: s/intel_vrr_compute_config_late/intel_vrr_compute_guardband Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 11/16] drm/i915/vblank: Add helper to get correct vblank length Ankit Nautiyal
2025-10-06 19:56 ` Ville Syrjälä
2025-10-07 5:52 ` Nautiyal, Ankit K
2025-10-07 15:16 ` Ville Syrjälä [this message]
2025-10-07 17:30 ` Ville Syrjälä
2025-10-08 6:34 ` Nautiyal, Ankit K
2025-10-06 4:28 ` [PATCH 12/16] drm/i915/vrr: Recompute vblank_start for platforms with always-on VRR TG Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 13/16] drm/i915/display: Add vblank_start adjustment logic for " Ankit Nautiyal
2025-10-06 19:56 ` Ville Syrjälä
2025-10-07 6:30 ` Nautiyal, Ankit K
2025-10-07 15:19 ` Ville Syrjälä
2025-10-06 4:28 ` [PATCH 14/16] drm/i915/vrr: Introduce helper to compute min static guardband Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 15/16] drm/i915/display: Use optimized guardband for always-on VRR TG Ankit Nautiyal
2025-10-06 4:28 ` [PATCH 16/16] drm/i915/vrr: Use optimized guardband when VRR TG is active Ankit Nautiyal
2025-10-06 4:54 ` ✓ CI.KUnit: success for Optimize vrr.guardband and fix LRR (rev14) Patchwork
2025-10-06 5:09 ` ✗ CI.checksparse: warning " Patchwork
2025-10-06 5:34 ` ✓ Xe.CI.BAT: success " Patchwork
2025-10-06 6:45 ` ✗ Xe.CI.Full: failure " Patchwork
2025-10-06 9:56 ` ✓ i915.CI.BAT: success for Optimize vrr.guardband and fix LRR (rev13) Patchwork
2025-10-06 11:54 ` ✗ i915.CI.Full: failure " Patchwork
2025-10-06 22:50 ` [PATCH 00/16] Optimize vrr.guardband and fix LRR Ville Syrjälä
2025-10-07 6:33 ` Nautiyal, Ankit K
2025-10-07 15:22 ` Ville Syrjälä
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=aOUu6WoGHhYv4mRy@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.