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

Matt Roper matthew.d.roper at intel.com
Wed Aug 26 11:07:26 PDT 2015


On Tue, Aug 25, 2015 at 09:33:41PM -0700, Hindman, Gavin wrote:
> 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?

Are you referring to the series

    [PATCH 00/10] drm/i915: Another WM rewrite to enable DDR DVFS on CHV

?  If so, then I believe the work here should be orthogonal to that.
Ville's work there primarily deals with how the VLV/CHV-style watermarks
are calculated in a hardware-specific manner, whereas my series is more
about precomputing state in general earlier in the atomic pipeline so
that we can program the right values at the right times later.  My
series allows the details for specific platforms to be transitioned over
one at a time without impacting the other platforms, and so far I've
only moved ILK-style and SKL-style WM's over; I haven't touched the
VLV/CHV-style yet.  When we have the core code in a state everyone is
happy with and get to transitioning VLV/CHV, I don't think there should
be any conflicts with Ville's work.

Ville did have one general, platform-independent patch at the beginning of
his series, but my work should already be rebased to build on top of
that, so no concerns there.


Matt

> 
> 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

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795


More information about the Intel-gfx mailing list