On Thu, Jul 16, 2020 at 10:04:26PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
