From 4d6bde58a026c5cac263081c572aebe89bf32167 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Ville=20Syrj=C3=A4l=C3=A4?= Date: Thu, 16 Jul 2020 22:04:26 +0300 Subject: [PATCH] drm/i915: Apply WAC6entrylatency to kbl/cfl MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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->~44msec and 0x8000->~22msec we see in the graph. 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. v2: s/usec/msec/ typo in commit msg Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200716190426.17047-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson --- 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 ae6b367..0ef01a0 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7208,6 +7208,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 @@ -7227,6 +7231,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_GT_REVID(dev_priv, 0, KBL_REVID_B0)) I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) | -- 2.7.4