[PATCH 00/19] atomic, remixed

[Daniel Vetter]

On Sun, Jul 27, 2014 at 11:41:29PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> So I've figured instead of just talking I should draw up my ideas for atomic
> helpers and related stuff in some draft patches. Major differences compared to
> Rob's series:
> 
> - The software side state update is done synchronously, at least when using the
>   helper code. Drivers are free to do whatever they want, as usual. This has a
>   bunch of nice upsides:
> 
>   + All the tricky locking dances can be abolished, and if the ordering and
>     synchronization is done correctly async worker threads don't need any
>     modeset state locking at all. I'm fairly sure that Rob's scheme won't blow
>     up, but I much prefer we don't need it at all.
> 
>   + In Rob's patches any atomic operation must wait for outstanding updates to
>     complete. Otherwise the software state isn't committed yet. With the
>     synchronous updates we can immediately proceed with the state construction
>     and verification and will only block right before applying the state update.
>     And even for that drivers can implement cancellation of the previous update.
>     
>     This has the nice benefit that check-only operations (which compositors need
>     to do right after having completed the current frame to know how to render
>     the next one) can be done without blocking for completion of the previous
>     update.
> 
> - Internal interfaces for atomic updates don't need to go through properties,
>   but can directly set the state. Drivers can always compare updates in their
>   ->check hook later on, so we don't lose expressiveness in the interface. But
>   the resulting code in the callers looks much better.
> 
>   In general I've ditched a lot of interfaces where drivers could overwrite
>   default behaviour and boiled down the interface two state handling functions
>   (duplicate+destroy), setting driver-private properties and check/commit.
> 
> - There is a clear helper separation between core code which should be used to
>   use the atomic interface to drivers, and helper functions. Core never uses
>   helper functions so that we can keep the clear separation we have in all other
>   places in the kms api.
> 
>   There's a set of helpers sitting in-between to implement legacy interfaces on
>   top of atomic. Those _only_ use the core atomic interfaces.
> 
> - I've added a new set of plane helpers. Mostly this was motivated to make the
>   atomic helpers work on less stellar hardware where you can't just stream the
>   state and then atomically commit with some GO bits. But those helpers should
>   also be useful for more gradual transitions of drivers to the atomic
>   interface. Since a requirement for atomic is to have universal plane support
>   they can be used bare-bones just for that, without all the other atomic
>   baggage (i.e. all the state tracking for crtcs/connectors).
> 
> - State tracking for connectors. i915 has piles of relevant connector
>   properties, which we want to save/restore in atomic ops (e.g. hdmi metadata
>   and stuff).
> 
> - fbdev panic locking is implemented with trylock instead of nolock.
> 
> - I've thought a bit about resume. See the proposed state handling for the
>   default reset functions and the addition of a plane reset callback.
> 
> There's also a metric pile of stuff missing:
> 
> - It's completely untested (except for the parts touching currently used code)
>   since I lack suitable hw. Converting i915 is just a bit too much of a pain for
>   a quick w/e code draft ;-)
> 
> - I didn't add all the properties for things currently exposed through ioctl
>   structures. Since the interface here doesn't force internal code to use
>   properties for everything (which really makes things look much better) we
>   don't have a need for that until we merge the actual atomic ioctl. So I left
>   that out.
> 
> - I didn't write code for the fbdev helper to use atomic. The w/e ran out of
>   time for that ...
> 
> - Kerneldoc is occasionally not updated or still missing.
> 
> Anyway I think this draft code is good enough to explain how I'd like to address
> some of the concerns I have with the current atomic code. Comments, flames and
> ideas highly welcome. And if anyone is insane enought to try this on real
> hardware, that would certainly be interesting and I'm very much willing to help
> out as much as possible ... i915 just really isn't suitable since it won't be
> using the helpers, and all the other hw I have here doesn't support planes.

The entire thing is available as a git tree at

	git://people.freedesktop.org/~danvet/drm colder-fusion

I've already pushed a bit more polish on top.
-Daniel

> 
> Cheers, Daniel
> 
> Daniel Vetter (18):
>   drm: Add atomic driver interface definitions for objects
>   drm: Add drm_plane/connector_index
>   drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]
>   drm: Handle legacy per-crtc locking with full acquire ctx
>   drm: Global atomic state handling
>   drm: Add atomic/plane helpers
>   drm/irq: Implement a generic vblank_wait function
>   drm/i915: Use generic vblank wait
>   drm/plane-helper: transitional atomic plane helpers
>   drm/crtc-helper: Transitional functions using atomic plane helpers
>   drm: Atomic crtc/connector updates using crtc helper interfaces
>   drm: Move ->old_fb from crtc to plane
>   drm/atomic-helper: implementatations for legacy interfaces
>   drm/plane-helper: Add async mode to prepare_fb
>   drm/atomic-helpers: document how to implement async commit
>   drm/atomic-helper: implement ->page_flip
>   drm: trylock modest locking for fbdev panics
>   drm/atomic-helpers: functions for state duplicate/destroy/reset
> 
> Ville Syrjälä (1):
>   drm: Add drm_crtc_vblank_waitqueue()
> 
>  Documentation/DocBook/drm.tmpl       |    1 +
>  drivers/gpu/drm/Makefile             |    4 +-
>  drivers/gpu/drm/drm_atomic.c         |  529 ++++++++++++
>  drivers/gpu/drm/drm_atomic_helper.c  | 1570 ++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/drm_crtc.c           |  194 ++---
>  drivers/gpu/drm/drm_crtc_helper.c    |  139 +++
>  drivers/gpu/drm/drm_fb_helper.c      |   10 +-
>  drivers/gpu/drm/drm_irq.c            |   45 +
>  drivers/gpu/drm/drm_modeset_lock.c   |  204 ++++-
>  drivers/gpu/drm/drm_plane_helper.c   |  181 +++-
>  drivers/gpu/drm/i915/intel_display.c |   41 +-
>  include/drm/drmP.h                   |   13 +
>  include/drm/drm_atomic.h             |   63 ++
>  include/drm/drm_atomic_helper.h      |   98 +++
>  include/drm/drm_crtc.h               |  208 ++++-
>  include/drm/drm_crtc_helper.h        |   13 +
>  include/drm/drm_modeset_lock.h       |   16 +
>  include/drm/drm_plane_helper.h       |   31 +
>  18 files changed, 3188 insertions(+), 172 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_atomic.c
>  create mode 100644 drivers/gpu/drm/drm_atomic_helper.c
>  create mode 100644 include/drm/drm_atomic.h
>  create mode 100644 include/drm/drm_atomic_helper.h
> 
> -- 
> 2.0.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch