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@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Matt Roper Sent: Thursday, August 20, 2015 6:12 PM To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx Cc: Conselvan De Oliveira, Ander Subject: [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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
