[PATCH 0/4] Misc atomic-related updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Here's a few atomic-related patches that I've developed in the process of
preparing the atomic watermark code.  I think some of this code is also
useful/important for other features that are being developed (e.g., SKL
scalers), so I'm extracting these and posting them early to get feedback and
possibly smooth the way for other developers.

The first patch here makes our atomic plane updates stop keying off
intel_crtc->active when generating their derived state.  This will be important
when we start handling CRTC state updates as part of an atomic transaction, or
even when we call our plane update functions from within a legacy modeset path.

The second patch updates some fragile plane => crtc mapping that works okay
today, but will definitely cause problems once we merge support for
non-blocking atomic flips.

The third patch switches our update_plane/disable_plane handlers back to the
full atomic helpers.  This caused a lot of breakage last time we tried, but we
try to sidestep those problems this time by replacing the plane vfunc calls we
still have in our legacy modeset path to call the transitional plane helpers
directly.  The important thing here is that we want to ensure legacy SetPlane()
calls from userspace have a top-level atomic transaction since a few pieces of
upcoming code really need this (SKL scalers, atomic watermarks, etc.).

The fourth patch fixes what I believe is a bug in our existing code (but not
one that anyone has stumbled over yet afaik).  Since crtc states aren't fully
wired up for i915 yet, we've been using intel_crtc->atomic as a temporary
dumping ground for stuff that will eventually transition to the CRTC state.  We
properly clear that structure out at the end of a successful atomic transaction
so that we'll start fresh on the next transaction, but we neglect to do so if
the transaction doesn't make it to the commit stage (e.g., because 'check'
failed).  I'm surprised having stale flags from a previous transaction's
'check' hasn't already caused problems for us, but I guess we've just been
lucky.



Matt Roper (4):
  drm/i915: Make atomic use in-flight state for CRTC active value
  drm/i915: Lookup CRTC for plane directly
  drm/i915: Switch to full atomic helpers for plane updates/disable,
    take two
  drm/i915: Clear crtc atomic flags at beginning of transaction

 drivers/gpu/drm/i915/intel_atomic.c       |  18 +++++
 drivers/gpu/drm/i915/intel_atomic_plane.c |  23 ++++---
 drivers/gpu/drm/i915/intel_display.c      | 107 ++++++++++++++++++++++++------
 drivers/gpu/drm/i915/intel_drv.h          |  11 +++
 drivers/gpu/drm/i915/intel_sprite.c       |  30 ++++++---
 5 files changed, 149 insertions(+), 40 deletions(-)

-- 
1.8.5.1

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





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux