1. 06 Aug, 2018 3 commits
    • Mika Kuoppala's avatar
      Revert "drm/i915/icl: WaEnableFloatBlendOptimization" · 497bfb70
      Mika Kuoppala authored
      The register for 0xe420 is unable to hold any value, including
      this bit. The documentation is also mixed between having a
      register bit for toggle and having a state command setup
      for it. Apparently the register toggle is deprecated.
      
      Remove the register toggle as evidence shows it's futile.
      
      The thing remaining is an apology and humble request for
      Mesa folks to resurrect their state setup for this as they
      were on right track from start.
      
      This reverts commit 0bf059f3.
      
      Fixes: 0bf059f3 ("drm/i915/icl: WaEnableFloatBlendOptimization")
      References: HSDES#1406393558
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Cc: Anuj Phogat <anuj.phogat@gmail.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180730120636.26958-1-mika.kuoppala@linux.intel.com
      (cherry picked from commit c358514b)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      497bfb70
    • Chris Wilson's avatar
      drm/i915: Interactive RPS mode · 027063b1
      Chris Wilson authored
      RPS provides a feedback loop where we use the load during the previous
      evaluation interval to decide whether to up or down clock the GPU
      frequency. Our responsiveness is split into 3 regimes, a high and low
      plateau with the intent to keep the gpu clocked high to cover occasional
      stalls under high load, and low despite occasional glitches under steady
      low load, and inbetween. However, we run into situations like kodi where
      we want to stay at low power (video decoding is done efficiently
      inside the fixed function HW and doesn't need high clocks even for high
      bitrate streams), but just occasionally the pipeline is more complex
      than a video decode and we need a smidgen of extra GPU power to present
      on time. In the high power regime, we sample at sub frame intervals with
      a bias to upclocking, and conversely at low power we sample over a few
      frames worth to provide what we consider to be the right levels of
      responsiveness respectively. At low power, we more or less expect to be
      kicked out to high power at the start of a busy sequence by waitboosting.
      
      Prior to commit e9af4ea2 ("drm/i915: Avoid waitboosting on the active
      request") whenever we missed the frame or stalled, we would immediate go
      full throttle and upclock the GPU to max. But in commit e9af4ea2, we
      relaxed the waitboosting to only apply if the pipeline was deep to avoid
      over-committing resources for a near miss. Sadly though, a near miss is
      still a miss, and perceptible as jitter in the frame delivery.
      
      To try and prevent the near miss before having to resort to boosting
      after the fact, we use the pageflip queue as an indication that we are
      in an "interactive" regime and so should sample the load more frequently
      to provide power before the frame misses it vblank. This will make us
      more favorable to providing a small power increase (one or two bins) as
      required rather than going all the way to maximum and then having to
      work back down again. (We still keep the waitboosting mechanism around
      just in case a dramatic change in system load requires urgent uplocking,
      faster than we can provide in a few evaluation intervals.)
      
      v2: Reduce rps_set_interactive to a boolean parameter to avoid the
      confusion of what if they wanted a new power mode after pinning to a
      different mode (which to choose?)
      v3: Only reprogram RPS while the GT is awake, it will be set when we
      wake the GT, and while off warns about being used outside of rpm.
      v4: Fix deferred application of interactive mode
      v5: s/state/interactive/
      v6: Group the mutex with its principle in a substruct
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111
      Fixes: e9af4ea2 ("drm/i915: Avoid waitboosting on the active request")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk
      (cherry picked from commit 60548c55)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      027063b1
    • Rodrigo Vivi's avatar
      drm/i915: Fix psr sink status report. · 656921a5
      Rodrigo Vivi authored
      First of all don't try to read dpcd if PSR is not even supported.
      
      But also, if read failed return -EIO instead of reporting via a
      backchannel.
      
      v2: fix dev_priv: At this level m->private is the connector. (CI/DK)
          don't convert dpcd read errors to EIO. (DK)
      
      Fixes: 5b7b3086 ("drm/i915/psr: Split sink status into a separate debugfs node")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180720003155.16290-1-rodrigo.vivi@intel.com
      (cherry picked from commit 7a72c78b)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      656921a5
  2. 31 Jul, 2018 2 commits
  3. 30 Jul, 2018 35 commits