intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Souza, Jose" <jose.souza@intel.com>
To: "Mun, Gwan-gyeong" <gwan-gyeong.mun@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2 5/8] drm/i915/display: Share code between intel_drrs_flush and intel_drrs_invalidate
Date: Fri, 3 Sep 2021 21:52:53 +0000	[thread overview]
Message-ID: <9abd7d37254dfe54039cb5a467cd2f76bed5524c.camel@intel.com> (raw)
In-Reply-To: <35c7c5af-27aa-9e52-fbb0-5c48bac5feab@intel.com>

On Thu, 2021-09-02 at 18:57 +0300, Gwan-gyeong Mun wrote:
> 
> On 8/25/21 3:58 AM, José Roberto de Souza wrote:
> > Both functions are pretty much equal, with minor changes that can be
> > handled by a single parameter.
> > 
> > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > ---
> >   drivers/gpu/drm/i915/display/intel_drrs.c | 82 +++++++++--------------
> >   1 file changed, 32 insertions(+), 50 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c b/drivers/gpu/drm/i915/display/intel_drrs.c
> > index 5eb5033242575..8583da4e82434 100644
> > --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> > @@ -312,18 +312,9 @@ static void intel_drrs_downclock_work(struct work_struct *work)
> >   	mutex_unlock(&dev_priv->drrs.mutex);
> >   }
> >   
> > -/**
> > - * intel_drrs_invalidate - Disable Idleness DRRS
> > - * @dev_priv: i915 device
> > - * @frontbuffer_bits: frontbuffer plane tracking bits
> > - *
> > - * This function gets called everytime rendering on the given planes start.
> > - * Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR).
> > - *
> > - * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits.
> > - */
> > -void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
> > -			   unsigned int frontbuffer_bits)
> > +static void intel_drrs_frontbuffer_update(struct drm_i915_private *dev_priv,
> > +					  unsigned int frontbuffer_bits,
> > +					  bool invalidate)
> >   {
> >   	struct intel_dp *intel_dp;
> >   	struct drm_crtc *crtc;
> > @@ -346,16 +337,42 @@ void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
> >   	pipe = to_intel_crtc(crtc)->pipe;
> >   
> >   	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
> > -	dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
> > +	if (invalidate)
> > +		dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
> > +	else
> > +		dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
> >   
> > -	/* invalidate means busy screen hence upclock */
> > +	/* flush/invalidate means busy screen hence upclock */
> >   	if (frontbuffer_bits)
> >   		intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
> >   				     DRRS_HIGH_RR);
> >   
> > +	/*
> > +	 * flush also means no more activity hence schedule downclock, if all
> > +	 * other fbs are quiescent too
> > +	 */
> > +	if (!dev_priv->drrs.busy_frontbuffer_bits)
> > +		schedule_delayed_work(&dev_priv->drrs.work,
> > +				      msecs_to_jiffies(1000));
> This line of code was previously only used in the intel_drrs_flush() 
> function,
> In the case of the intel_drrs_invalidate() call scenario, it is not 
> confirmed whether dev_priv->drrs.busy_frontbuffer_bits is always true to 
> me. If it's not always true, it looks like you also need to check for 
> "not invalidate".
> Please ignore this comment if I'm wrong.

Huum yeah if there is a invalidate in another pipe that could delay the work to be executed or execute it without needing it.

Will change it to: if (!invalidate && !dev_priv->drrs.busy_frontbuffer_bit) It should handle this cases above.

Thanks for the catch again.

> 
> >   	mutex_unlock(&dev_priv->drrs.mutex);
> >   }
> >   
> > +/**
> > + * intel_drrs_invalidate - Disable Idleness DRRS
> > + * @dev_priv: i915 device
> > + * @frontbuffer_bits: frontbuffer plane tracking bits
> > + *
> > + * This function gets called everytime rendering on the given planes start.
> > + * Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR).
> > + *
> > + * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits.
> > + */
> > +void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
> > +			   unsigned int frontbuffer_bits)
> > +{
> > +	intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, true);
> > +}
> > +
> >   /**
> >    * intel_drrs_flush - Restart Idleness DRRS
> >    * @dev_priv: i915 device
> > @@ -371,42 +388,7 @@ void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
> >   void intel_drrs_flush(struct drm_i915_private *dev_priv,
> >   		      unsigned int frontbuffer_bits)
> >   {
> > -	struct intel_dp *intel_dp;
> > -	struct drm_crtc *crtc;
> > -	enum pipe pipe;
> > -
> > -	if (dev_priv->drrs.type == DRRS_NOT_SUPPORTED)
> > -		return;
> > -
> > -	cancel_delayed_work(&dev_priv->drrs.work);
> > -
> > -	mutex_lock(&dev_priv->drrs.mutex);
> > -
> > -	intel_dp = dev_priv->drrs.dp;
> > -	if (!intel_dp) {
> > -		mutex_unlock(&dev_priv->drrs.mutex);
> > -		return;
> > -	}
> > -
> > -	crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
> > -	pipe = to_intel_crtc(crtc)->pipe;
> > -
> > -	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
> > -	dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
> > -
> > -	/* flush means busy screen hence upclock */
> > -	if (frontbuffer_bits)
> > -		intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
> > -				     DRRS_HIGH_RR);
> > -
> > -	/*
> > -	 * flush also means no more activity hence schedule downclock, if all
> > -	 * other fbs are quiescent too
> > -	 */
> > -	if (!dev_priv->drrs.busy_frontbuffer_bits)
> > -		schedule_delayed_work(&dev_priv->drrs.work,
> > -				      msecs_to_jiffies(1000));
> > -	mutex_unlock(&dev_priv->drrs.mutex);
> > +	intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, false);
> >   }
> >   
> >   /**
> > 


  reply	other threads:[~2021-09-03 21:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25  0:58 [Intel-gfx] [PATCH v2 0/8] Drop frontbuffer rendering support from Skylake and newer José Roberto de Souza
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 1/8] drm/i915/display: Drop PSR support from HSW and BDW José Roberto de Souza
2021-08-25 15:50   ` Rodrigo Vivi
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 2/8] drm/i915/display: Move DRRS code its own file José Roberto de Souza
2021-08-25 15:55   ` Rodrigo Vivi
2021-08-25 17:23     ` Souza, Jose
2021-08-25 18:52       ` Rodrigo Vivi
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 3/8] drm/i915/display: Renaming DRRS functions to intel_drrs_*() José Roberto de Souza
2021-08-25 15:56   ` Rodrigo Vivi
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 4/8] drm/i915/display: Some code improvements and code style fixes for DRRS José Roberto de Souza
2021-09-02 15:15   ` Gwan-gyeong Mun
2021-09-03 20:36     ` Souza, Jose
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 5/8] drm/i915/display: Share code between intel_drrs_flush and intel_drrs_invalidate José Roberto de Souza
2021-09-02 15:57   ` Gwan-gyeong Mun
2021-09-03 21:52     ` Souza, Jose [this message]
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 6/8] drm/i915/display: Prepare DRRS for frontbuffer rendering drop José Roberto de Souza
2021-09-02 16:09   ` Gwan-gyeong Mun
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support José Roberto de Souza
2021-09-02 18:42   ` Gwan-gyeong Mun
2021-09-03 22:09     ` Souza, Jose
2021-09-04  0:26       ` Souza, Jose
2021-09-06  9:44         ` Gwan-gyeong Mun
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 8/8] drm/i915/display: Drop PSR " José Roberto de Souza
2021-09-06 16:05   ` Gwan-gyeong Mun
2021-08-25  1:01 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Drop frontbuffer rendering support from Skylake and newer (rev2) Patchwork
2021-08-25  1:03 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-08-25  1:33 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-08-25 15:57 ` [Intel-gfx] [PATCH v2 0/8] Drop frontbuffer rendering support from Skylake and newer Rodrigo Vivi

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=9abd7d37254dfe54039cb5a467cd2f76bed5524c.camel@intel.com \
    --to=jose.souza@intel.com \
    --cc=gwan-gyeong.mun@intel.com \
    --cc=intel-gfx@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).