[Intel-gfx] [PATCH 00/13] Atomic watermark updates (v3)

[Hindman, Gavin]

Does this series comprehend all of the ddr-dvfs/PM-5 watermark reworks that Ville did towards the end of CHV, or is this series additive to that?

Gavin Hindman
Senior Program Manager
SSG/OTC – Open Source Technology Center


-----Original Message-----
From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of Matt Roper
Sent: Thursday, August 20, 2015 6:12 PM
To: intel-gfx at lists.freedesktop.org
Cc: Conselvan De Oliveira, Ander
Subject: [Intel-gfx] [PATCH 00/13] Atomic watermark updates (v3)

Previous atomic watermark patches were posted here:
  http://lists.freedesktop.org/archives/intel-gfx/2015-July/070465.html

Key changes since the last series:
 * Quite a bit of rebasing; I got pulled away from working on this for a while,
   so parts of the upstream code evolved a bit before I was able to get back
   to working on this.
 * Completely drop the async aspect of writing the final watermarks on
   platforms that need two-step programming.  Although this is the direction we
   want to go eventually, Maarten has indicated that what I was doing in
   previous patch sets was going to lead to conflicts with some of his
   in-progress work and asked that I just write the final watermarks at the
   very end of the atomic transaction, after waiting for vblanks.  We can
   revisit the async final step again after Maarten's work lands and leverage
   the new interfaces he adds.  In the meantime, this simplifies things a
   bit since we don't need to worry about async final watermark writing
   racing with our next transaction and clobbering the intermediate values
   for that next transaction that we've already written.
 * Early SKL-style atomic watermarks (completely untested at the moment!).  Even
   though gen9 doesn't need the two-step programming process, we now
   pre-compute gen9 watermark values during the check phase and write+flush
   them during commit.  However I think there's still more refactoring that
   should be eventually done here.  We trigger watermark updates on a per-crtc
   basis, but the end results are global, not per-crtc.  In an atomic
   transaction this could currently lead to us re-calculating the same values
   multiple times if multiple CRTC's all trigger a WM update.   Note that I
   haven't had a chance to run any of this on real gen9 hardware yet, so all of
   the SKL patches here should be considered RFC at best; they may be
   completely broken.
 * Various review feedback from Daniel, Ville, and Maarten from previous
   iterations.


Matt Roper (12):
  drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM
    code
  drm/i915: Eliminate usage of pipe_wm_parameters from ILK-style WM
  drm/i915/skl: Simplify wm structures slightly
  drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM
  drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check
  drm/i915: Drop intel_update_sprite_watermarks
  drm/i915: Move active watermarks into CRTC state (v2)
  drm/i915: Calculate ILK-style watermarks during atomic check (v2)
  drm/i915: Calculate watermark configuration during atomic check
  drm/i915: Add two-stage ILK-style watermark programming (v3)
  drm/i915/skl: Switch to atomic watermark programming
  drm/i915/skl: Clarify pending vs hw watermark values

Ville Syrjälä (1):
  drm/i915: Refactor ilk_update_wm (v3)

 drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h      |  68 ++-
 drivers/gpu/drm/i915/intel_atomic.c  |   1 +
 drivers/gpu/drm/i915/intel_display.c | 184 +++++++-
 drivers/gpu/drm/i915/intel_drv.h     |  81 +++-
 drivers/gpu/drm/i915/intel_pm.c      | 860 ++++++++++++++++-------------------
 drivers/gpu/drm/i915/intel_sprite.c  |  15 -
 7 files changed, 659 insertions(+), 554 deletions(-)

-- 
2.1.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx