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);
> > }
> >
> > /**
> >
next prev parent 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).