From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915: Apply WAC6entrylatency to kbl/cfl
Date: Thu, 15 Oct 2020 15:58:11 +0300 [thread overview]
Message-ID: <20201015125811.GK6112@intel.com> (raw)
In-Reply-To: <20200716190426.17047-2-ville.syrjala@linux.intel.com>
On Thu, Jul 16, 2020 at 10:04:26PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> WAC6entrylatency is trying to fix excessive rc6 entry latency caused
> by the extra delay from FBC_LLC_READ_CTRL, which is there for some
> extra sync with uncore for frame buffer caching in LLC.
>
> Reading through the hsd the recommendation was to set the FBC_LLC_FULLY_OPEN
> bit to disable this extra delay entirely. This can be done whenever fb LLC
> caching is not used. The alternative suggestion was to reduce the delay to
> eg. 0x5 via updated BIOS programming instructions. But all the kbl/cfl
> machines I've seen still have the default 0xff programmed. As we never use
> fb LLC caching let's just apply the w/a to all skl derivatives to get
> consistent rc6 latencies.
>
> I was able to measure the effect of FBC_LLC_READ_CTRL to rc6 latency
> via forcewake. Here's a graph of some of the results:
>
> sleep;fw_req=1;wait fw_ack==1;sleep;fw_req=0;wait fw_ack==0
> fw_ack==1 duration
> 160us +----------------------------------------------------------------+
> | + + $$+ + + |
> | $$ $ $ ******$$ ** $ $**$* #########$$######|
> 140us |-$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$*$$$$$$$$$$$$$$$$ $$$$$$|
> | $ * # |
> | $ * # |
> 120us |$+ * # +-|
> |$ * # |
> |$ * # # |
> 100us |$+ ************######################## +-|
> |$ * *# |
> |$ ***** ######### |
> 80us |$+ * # #### ## +-|
> |$ **** ### # # |
> | ** #### FBC_LLC_READ_CTRL: 0x8000 ******* |
> 60us |-###### FBC_LLC_READ_CTRL: 0xffff #######-|
> |## + + FBC_LLC_READ_CTRL: 0x400000ff $$$$$$$ |
> +----------------------------------------------------------------+
> 0ms 10ms 20ms 30ms 40ms 50ms 60ms
> sleep duration
>
> The default FBC_LLC_READ_CTRL value of 0xff is documented to give us
> a 170usec delay. That tracks well with the knees at 0xffff->~44usec and
> 0x8000->~22usec we see in the graph.
Those should obviously say msec instead of usec.
>
> We can see that if we sleep longer than the FBC_LLC_READ_CTRL delay
> we always observe the full (~145usec) rc6 wakeup latency. But if we sleep
> for less than the FBC_LLC_READ_CTRL delay we see a quicker fw wakeup,
> presumably due the hardware not having yet entered rc6 fully.
> The other plateaus in the graph I suspect correspond to some shallower
> internal rc states.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_pm.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0a1a95060f38..3998aa00563e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7197,6 +7197,10 @@ static void cfl_init_clock_gating(struct drm_i915_private *dev_priv)
> cnp_init_clock_gating(dev_priv);
> gen9_init_clock_gating(dev_priv);
>
> + /* WAC6entrylatency:cfl */
> + I915_WRITE(FBC_LLC_READ_CTRL, I915_READ(FBC_LLC_READ_CTRL) |
> + FBC_LLC_FULLY_OPEN);
> +
> /*
> * WaFbcTurnOffFbcWatermark:cfl
> * Display WA #0562: cfl
> @@ -7216,6 +7220,10 @@ static void kbl_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> gen9_init_clock_gating(dev_priv);
>
> + /* WAC6entrylatency:kbl */
> + I915_WRITE(FBC_LLC_READ_CTRL, I915_READ(FBC_LLC_READ_CTRL) |
> + FBC_LLC_FULLY_OPEN);
> +
> /* WaDisableSDEUnitClockGating:kbl */
> if (IS_KBL_REVID(dev_priv, 0, KBL_REVID_B0))
> I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
> --
> 2.26.2
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-10-15 12:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-16 19:04 [Intel-gfx] [PATCH 1/2] drm/i915: Move WaDisableDopClockGating:skl to skl_init_clock_gating() Ville Syrjala
2020-07-16 19:04 ` [Intel-gfx] [PATCH 2/2] drm/i915: Apply WAC6entrylatency to kbl/cfl Ville Syrjala
2020-10-15 12:58 ` Ville Syrjälä [this message]
2020-10-15 20:19 ` Chris Wilson
2020-07-16 19:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move WaDisableDopClockGating:skl to skl_init_clock_gating() Patchwork
2020-07-16 23:27 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-07-16 23:50 ` [Intel-gfx] [PATCH 1/2] " Souza, Jose
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=20201015125811.GK6112@intel.com \
--to=ville.syrjala@linux.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 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.