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 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent
Date: Wed, 17 Nov 2021 23:04:05 +0200 [thread overview]
Message-ID: <YZVuRQvAFT4xwC5M@intel.com> (raw)
In-Reply-To: <20211117211006.GB593@labuser-Z97X-UD5H>
On Wed, Nov 17, 2021 at 01:10:13PM -0800, Navare, Manasi wrote:
> On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Let's adjust the vblank evasion to account for the case where
> > a push has already been sent. In that case the vblank exit will start
> > at vmin vblank start (as opposed to vmax vblank start when no push
> > has been sent).
> >
> > This should minimize the effects of the tiny race between sampling
> > the frame counter vs. intel_vrr_send_push() during the previous frame.
> > This will also be required if we want to do mailbox style updates with
> > vrr since then we'd definitely do multiple commits per frame. Currently
> > mailbox updates are only used by the legacy cursor, but we don't do
> > vrr push for those.
> >
> > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++++++---
> > drivers/gpu/drm/i915/display/intel_vrr.c | 12 ++++++++++++
> > drivers/gpu/drm/i915/display/intel_vrr.h | 1 +
> > 3 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index cf403be7736c..eb5444f90e77 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state *new_crtc_state)
> > if (intel_crtc_needs_vblank_work(new_crtc_state))
> > intel_crtc_vblank_work_init(new_crtc_state);
> >
> > - if (new_crtc_state->vrr.enable)
> > - vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > - else
> > + if (new_crtc_state->vrr.enable) {
> > + if (intel_vrr_is_push_sent(new_crtc_state))
> > + vblank_start = intel_vrr_vmin_vblank_start(new_crtc_state);
>
> Actually if Push is sent then the vblank gets terminated at that point which falls between vmin and vmax so
> not necessarily at Vmin but at anytime between vmin and vmax. Is it correct to calculate it based on vmin?
If you do a push between vmin and vmax then the vblank terminates
immediately and the PUSH_SEND bit gets cleared. The only way the bit
stays set is you set it after vmax/before vmin.
>
> > + else
> > + vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > + } else {
> > vblank_start = intel_mode_vblank_start(adjusted_mode);
> > + }
> >
> > /* FIXME needs to be calibrated sensibly */
> > min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> > index c335b1dbafcf..db1c3902fc2d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
> > TRANS_PUSH_EN | TRANS_PUSH_SEND);
> > }
> >
> > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > +
> > + if (!crtc_state->vrr.enable)
> > + return false;
> > +
> > + return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & TRANS_PUSH_SEND;
>
> But HW clears this bit after double buffer update. Is this a good inidcation to check the PUSH_SEND bit?
>
> Manasi
>
> > +}
> > +
> > void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h b/drivers/gpu/drm/i915/display/intel_vrr.h
> > index 96f9c9c27ab9..1c2da572693d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> > @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
> > void intel_vrr_enable(struct intel_encoder *encoder,
> > const struct intel_crtc_state *crtc_state);
> > void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
> > void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
> > void intel_vrr_get_config(struct intel_crtc *crtc,
> > struct intel_crtc_state *crtc_state);
> > --
> > 2.32.0
> >
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2021-11-17 21:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 18:31 [Intel-gfx] [PATCH 1/3] drm/i915: Move vrr push after the frame counter sampling again Ville Syrjala
2021-11-17 18:31 ` [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent Ville Syrjala
2021-11-17 21:10 ` Navare, Manasi
2021-11-17 21:04 ` Ville Syrjälä [this message]
2021-11-17 23:09 ` Navare, Manasi
2021-11-18 18:52 ` Navare, Manasi
2021-11-17 18:31 ` [Intel-gfx] [PATCH 3/3] drm/i915: Fix framestart_delay commens in VRR code Ville Syrjala
2021-11-17 21:15 ` Navare, Manasi
2021-11-17 21:03 ` [Intel-gfx] [PATCH 1/3] drm/i915: Move vrr push after the frame counter sampling again Navare, Manasi
2021-11-17 23:20 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] " 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=YZVuRQvAFT4xwC5M@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox