[Intel-gfx] [PATCH 00/15] Accurate frontbuffer tracking and psr conversion

[Daniel Vetter]

Hi all,

This patch series adds accurate frontbuffer tracking to i915 and then converts
psr over to use. Bunch of things still need to be done.

- PSR needs to be re-tested. I lack the hardware for that. The frontbuffer
  tracking itself is tested.

- PSR igt testcase needs to be extended so that we cover all upload methods on
  all plane types.

- DRRS/downclocking needs to be unified and put into this framework properly.
  Also needs proper locking for all of the DRRS state.

- fbc also needs to be fixed up, with state handling properly split between
  crtc_enable/disable, primary fb updates and the fb tracking for nuking. A bit
  unclear how we want to integrate gtt cpu write tracking through the hw, since
  that seems to be the hw tracking piece that actually works.

General blueprint for display runtime power saving features:
- Have all your state in either intel_crtc or dev_priv, protected by its own
  lock.

- Do state setup in crtc_enable, cleanup in crtc_disable with a pair of
  enable/disable fuctions. Optionally update everywhere else you want (e.g.
  primary plane updates for fbc). Not state setup anywhere else allowed, except
  maybe an _init for setting up work items, locks, ...

- Intercept the invalidation/flush signals you need like
  psr_invalidate/psr_flush. Track internally which frontbuffer bits you're
  interested in and invalidate/flush accordingly. You can also use these for
  workarounds (e.g. on hsw we force-flush for sprite changes since the flip
  signal doesn't result in a hw image upload).


Note that currently the gtt tracking has a bit a gap: We never exit it. Bunch of
fixes are possible:
- Wire up the core dirty_fb ioctl to flush framebuffers. This is used by generic
  userspace to flush dummy buffers, which in our case means gtt mmaps. So maps
  perfectly.

- Do a delayed gtt pte teardown and force-flush. Probably too ugly to care
  really.

- Try to integrate hw gtt write tracking logic. Note that current psr code
  doesn't rely on this - I've killed the X-tiled checks completely.

Big thanks to Chris for some great ideas for the fb tracking scheme and the
precise placement of the invalidate/flush functions.

Comments, flames and especially testing on psr hardware highly welcome.

Cheers, Daniel

Daniel Vetter (15):
  drm/i915: Add missing statics to recent psr functions
  drm/i915: Drop unecessary complexity from psr_inactivate
  drm/i915: Ditch intel_edp_psr_update
  drm/i915: Run psr_setup unconditionally
  drm/i915: Drop schedule_back from psr_exit
  drm/i915: Add a FIXME about drrs/psr interactions
  drm/i915: Track the psr dp connector in dev_priv->psr.enabled
  drm/i915: Don't try to disable psr harder from the work item
  drm/i915: Lock down psr sw/hw state tracking
  drm/i915: More checks for psr.enabled
  drm/i915: Add locking to psr code
  drm/i915: Introduce accurate frontbuffer tracking
  drm/i915: Use new frontbuffer bits to increase pll clock
  drm/i915: Track frontbuffer invalidation/flushing
  drm/i915: Fix up PSR frontbuffer tracking

 drivers/gpu/drm/i915/i915_debugfs.c        |   2 +-
 drivers/gpu/drm/i915/i915_drv.h            |  46 ++++-
 drivers/gpu/drm/i915/i915_gem.c            |  38 +++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c       | 283 +++++++++++++++++++++++------
 drivers/gpu/drm/i915/intel_dp.c            | 189 +++++++++----------
 drivers/gpu/drm/i915/intel_drv.h           |  16 +-
 drivers/gpu/drm/i915/intel_fbdev.c         |  18 +-
 drivers/gpu/drm/i915/intel_overlay.c       |  14 ++
 drivers/gpu/drm/i915/intel_sprite.c        |  11 +-
 10 files changed, 458 insertions(+), 161 deletions(-)

-- 
2.0.0