All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Navare, Manasi" <manasi.d.navare@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915/vrr: Make registers latch in a consitent place on icl/tgl
Date: Wed, 7 Dec 2022 17:06:10 +0200	[thread overview]
Message-ID: <Y5Cr4ro8OQjDqeMD@intel.com> (raw)
In-Reply-To: <20221205201309.GA1208376@mdnavare-mobl1.jf.intel.com>

On Mon, Dec 05, 2022 at 12:13:09PM -0800, Navare, Manasi wrote:
> On Fri, Dec 02, 2022 at 03:44:09PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Account for the framestart delay when calculating the "pipeline full"
> > value for icl/tgl vrr. This puts the start of vblank (ie. where the
> > double bufferd registers get latched) to a consistent place regardless
> > of what framestart delay value is used. framestart delay does not
> > change where start of vblank occurs in non-vrr mode and I can't see
> > any reason why we'd want different behaviour in vrr mode.
> > 
> > Currently framestart delay is always set to 1, and the hardcoded 4
> > scanlines in the code means we're currently delaying the start of
> > vblank by three extra lines. And with framestart delay set to 4 we'd
> > have no extra delay.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> So now basically if we want to delay the vblank, then we will need to
> update framestart_delay to somethin other than 1.

No. framestart_delay does not affect where vblank starts. Or rather
it's not supposed to, but before this patch it was was affect when
VRR was enabled.

> Currently with framestart_delay = 1, there is no vblank delay, its just
> vrr.vmin - vdisplay so the vblank start right after?
> 
> Is this the correct understanding?
> 
> Anyway, if this logic is validated to work then should be fine.
> Basically this will only impact display <13, so as long as we dont
> regress anything on TGL then we should be good.
> 
> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> 
> Manasi
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_vrr.c | 13 ++-----------
> >  1 file changed, 2 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> > index 7b1357e82b69..6655dd2c1684 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > @@ -153,18 +153,9 @@ intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
> >  		crtc_state->vrr.guardband =
> >  			crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay;
> >  	} else {
> > -		/*
> > -		 * FIXME: s/4/framestart_delay/ to get consistent
> > -		 * earliest/latest points for register latching regardless
> > -		 * of the framestart_delay used?
> > -		 *
> > -		 * FIXME: this really needs the extra scanline to provide consistent
> > -		 * behaviour for all framestart_delay values. Otherwise with
> > -		 * framestart_delay==4 we will end up extending the min vblank by
> > -		 * one extra line.
> > -		 */
> >  		crtc_state->vrr.pipeline_full =
> > -			min(255, crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay - 4 - 1);
> > +			min(255, crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay -
> > +			    crtc_state->framestart_delay - 1);
> >  	}
> >  
> >  	crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
> > -- 
> > 2.37.4
> > 

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-12-07 15:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 13:44 [Intel-gfx] [PATCH 0/4] drm/i915/vrr: VRR fixes Ville Syrjala
2022-12-02 13:44 ` [Intel-gfx] [PATCH 1/4] drm/i915/vrr: Make registers latch in a consitent place on icl/tgl Ville Syrjala
2022-12-05 20:13   ` Navare, Manasi
2022-12-07 15:06     ` Ville Syrjälä [this message]
2022-12-02 13:44 ` [Intel-gfx] [PATCH 2/4] drm/i915/vrr: Fix guardband/vblank exit length calculation for adl+ Ville Syrjala
2022-12-05 20:34   ` Navare, Manasi
2022-12-07 15:10     ` Ville Syrjälä
2022-12-07 21:05       ` Navare, Manasi
2022-12-07 21:35         ` Ville Syrjälä
2022-12-08 18:42           ` Navare, Manasi
2022-12-02 13:44 ` [Intel-gfx] [PATCH 3/4] drm/i915/vrr: Reorder transcoder vs. vrr enable/disable Ville Syrjala
2022-12-05 20:48   ` Navare, Manasi
2022-12-02 13:44 ` [Intel-gfx] [PATCH 4/4] drm/i915/vrr: Be more careful with the bits in TRANS_VRR_CTL Ville Syrjala
2022-12-05 20:55   ` Navare, Manasi
2022-12-02 14:50 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/vrr: VRR fixes Patchwork
2022-12-02 15:23 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-12-07 17:05 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/vrr: VRR fixes (rev2) Patchwork
2022-12-07 17:24 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-07 22:34 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=Y5Cr4ro8OQjDqeMD@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=manasi.d.navare@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 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.