An error occurred fetching the project authors.
  1. 22 Jul, 2015 1 commit
    • Daniel Vetter's avatar
      drm: Roll out drm_for_each_connector more · 9a9f5ce8
      Daniel Vetter authored
      Now that we also grab the connection_mutex and so fixed the race with
      atomic modeset we can use the iterator there too.
      
      The other special case is drm_connector_unplug_all which would have a
      locking inversion with the sysfs store/show functions if we'd grab the
      mode_config.mutex around the unplug. We could just grab
      connection_mutex instead, but that's a bit too much a dirty trick for
      my taste. Also it's only used by udl, which doesn't do any other kind
      of connector hotplugging, so should be race-free. Hence just stick
      with a comment for now.
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      9a9f5ce8
  2. 07 Jul, 2015 1 commit
  3. 02 Jul, 2015 1 commit
  4. 19 Jun, 2015 1 commit
  5. 26 May, 2015 3 commits
  6. 21 May, 2015 1 commit
  7. 18 May, 2015 1 commit
  8. 13 May, 2015 1 commit
  9. 11 Apr, 2015 1 commit
  10. 07 Apr, 2015 1 commit
  11. 30 Mar, 2015 2 commits
  12. 23 Mar, 2015 2 commits
  13. 10 Mar, 2015 2 commits
  14. 23 Feb, 2015 1 commit
    • Daniel Vetter's avatar
      drm: Add DRM_DEBUG_ATOMIC · 17a38d9c
      Daniel Vetter authored
      Atomic state handling adds a lot of indirection and complexity between
      simple updates and drivers. For easier debugging the diagnostic output
      is therefore rather chatty. Which is great for tracking down atomic
      issues, but really annoying otherwise.
      
      Add a new DRM_DEBUG_ATOMIC to be able to filter this out.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      17a38d9c
  15. 27 Jan, 2015 3 commits
    • Ander Conselvan de Oliveira's avatar
      drm/atomic: Fix potential use of state after free · 9469244d
      Ander Conselvan de Oliveira authored
      The atomic helpers rely on drm_atomic_state_clear() to reset an atomic
      state if a retry is needed due to the w/w mutexes. The subsequent calls
      to drm_atomic_get_{crtc,plane,...}_state() would then return the stale
      pointers in state->{crtc,plane,...}_states.
      Signed-off-by: default avatarAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9469244d
    • Daniel Vetter's avatar
      drm/atomic: Add drm_crtc_state->active · eab3bbef
      Daniel Vetter authored
      This is the infrastructure for DPMS ported to the atomic world.
      Fundamental changes compare to legacy DPMS are:
      
      - No more per-connector dpms state, instead there's just one per each
        display pipeline. So if you clone either you have to unclone first
        if you only want to switch off one screen, or you just switch of
        everything (like all desktops do). This massively reduces complexity
        for cloning since now there's no more half-enabled cloned configs to
        consider.
      
      - Only on/off, dpms standby/suspend are as dead as real CRTs. Again
        reduces complexity a lot.
      
      Now especially for backwards compat the really important part for dpms
      support is that dpms on always succeeds (except for hw death and
      unplugged cables ofc). Which means everything that could fail (like
      configuration checking, resources assignments and buffer management)
      must be done irrespective from ->active. ->active is really only a
      toggle to change the hardware state. More precisely:
      
      - Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
        Changes to ->active MUST always suceed if nothing else changes.
      
      - Drivers using the atomic helpers MUST NOT look at ->active anywhere,
        period. The helpers will take care of calling the respective
        enable/modeset/disable hooks as necessary. As before the helpers
        will carefully keep track of the state and not call any hooks
        unecessarily, so still no double-disables or enables like with crtc
        helpers.
      
      - ->mode_set hooks are only called when the mode or output
        configuration changes, not for changes in ->active state.
      
      - Drivers which reconstruct the state objects in their ->reset hooks
        or through some other hw state readout infrastructure must ensure
        that ->active reflects actual hw state.
      
      This just implements the core bits and helper logic, a subsequent
      patch will implement the helper code to implement legacy dpms with
      this.
      
      v2: Rebase on top of the drm ioctl work:
      - Move crtc checks to the core check function.
      - Also check for ->active_changed when deciding whether a modeset
        might happen (for the ALLOW_MODESET mode).
      - Expose the ->active state with an atomic prop.
      
      v3: Review from Rob
      - Spelling fix in comment.
      - Extract needs_modeset helper to consolidate the ->mode_changed ||
        ->active_changed checks.
      
      v4: Fixup fumble between crtc->state and crtc_state.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarThierry Reding <treding@nvidia.com>
      Tested-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      eab3bbef
    • Matt Roper's avatar
      drm: Add rotation value to plane state · 1da30627
      Matt Roper authored
      The rotation property is shared by multiple drivers, so it makes sense
      to store the rotation value (for atomic-converted drivers) in the common
      plane state so that core code can eventually access it as well.
      
      Cc: dri-devel@lists.freedesktop.org
      Suggested-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Reviewed-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      1da30627
  16. 21 Jan, 2015 1 commit
  17. 05 Jan, 2015 6 commits
  18. 18 Dec, 2014 2 commits
  19. 17 Dec, 2014 1 commit
    • Daniel Vetter's avatar
      drm/atomic: Introduce state->obj backpointers · 07cc0ef6
      Daniel Vetter authored
      Useful since this way we can pass around just the state objects and
      will get ther real object, too.
      
      Specifically this allows us to again simplify the parameters for
      set_crtc_for_plane.
      
      v2: msm already has it's own specific plane_reset hook, don't forget
      that one!
      
      v3: Fixup kerneldoc, reported by 0-day builder.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Reviewed-by: Rob Clark <robdclark@gmail.com> (v2)
      Tested-by: Rob Clark <robdclark@gmail.com> (v2)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      07cc0ef6
  20. 27 Nov, 2014 1 commit
    • Rob Clark's avatar
      drm/atomic: track bitmask of planes attached to crtc · 6ddd388a
      Rob Clark authored
      Chasing plane->state->crtc of planes that are *not* part of the same
      atomic update is racy, making it incredibly awkward (or impossible) to
      do something simple like iterate over all planes and figure out which
      ones are attached to a crtc.
      
      Solve this by adding a bitmask of currently attached planes in the
      crtc-state.
      
      Note that the transitional helpers do not maintain the plane_mask.  But
      they only support the legacy ioctls, which have sufficient brute-force
      locking around plane updates that they can continue to loop over all
      planes to see what is attached to a crtc the old way.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      [danvet:
      - Drop comments about locking in set_crtc_for_plane since they're a
        bit misleading - we already should hold lock for the current crtc.
      - Also WARN_ON if get_state on the old crtc fails since that should
        have been done already.
      - Squash in fixup to check get_plane_state return value, reported by
        Dan Carpenter and acked by Rob Clark.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6ddd388a
  21. 25 Nov, 2014 1 commit
  22. 21 Nov, 2014 1 commit
  23. 20 Nov, 2014 3 commits
  24. 12 Nov, 2014 1 commit
    • Daniel Vetter's avatar
      drm: Per-plane locking · 4d02e2de
      Daniel Vetter authored
      Turned out to be much simpler on top of my latest atomic stuff than
      what I've feared. Some details:
      
      - Drop the modeset_lock_all snakeoil in drm_plane_init. Same
        justification as for the equivalent change in drm_crtc_init done in
      
      	commit d0fa1af4
      	Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      	Date:   Mon Sep 8 09:02:49 2014 +0200
      
      	    drm: Drop modeset locking from crtc init function
      
        Without these the drm_modeset_lock_init would fall over the exact
        same way.
      
      - Since the atomic core code wraps the locking switching it to
        per-plane locks was a one-line change.
      
      - For the legacy ioctls add a plane argument to the locking helper so
        that we can grab the right plane lock (cursor or primary). Since the
        universal cursor plane might not be there, or someone really crazy
        might forgoe the primary plane even accept NULL.
      
      - Add some locking WARN_ON to the atomic helpers for good paranoid
        measure and to check that it all works out.
      
      Tested on my exynos atomic hackfest with full lockdep checks and ww
      backoff injection.
      
      v2: I've forgotten about the load-detect code in i915.
      
      v3: Thierry reported that in latest 3.18-rc vmwgfx doesn't compile any
      more due to
      
      commit 21e88620
      Author: Rob Clark <robdclark@gmail.com>
      Date:   Thu Oct 30 13:39:04 2014 -0400
      
          drm/vmwgfx: fix lock breakage
      
      Rebased and fix this up.
      
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      4d02e2de
  25. 06 Nov, 2014 1 commit
    • Daniel Vetter's avatar
      drm/atomic: Refcounting for plane_state->fb · 321ebf04
      Daniel Vetter authored
      So my original plan was that the drm core refcounts framebuffers like
      with the legacy ioctls. But that doesn't work for a bunch of reasons:
      
      - State objects might live longer than until the next fb change
        happens for a plane. For example delayed cleanup work only happens
        _after_ the pageflip ioctl has completed. So this definitely doesn't
        work without the plane state holding its own references.
      
      - The other issue is transition from legacy to atomic implementations,
        where the driver works under a mix of both worlds. Which means
        legacy paths might not properly update the ->fb pointer under
        plane->state->fb. Which is a bit a problem when then someone comes
        around and _does_ try to clean it up when it's long gone.
      
      The second issue is just a bit a transition bug, since drivers should
      update plane->state->fb in all the paths that aren't converted yet.
      But a bit more robustness for the transition can't hurt - we pull
      similar tricks with cleaning up the old fb in the transitional helpers
      already.
      
      The pattern for drivers that transition is
      
      	if (plane->state)
      		drm_atomic_set_fb_for_plane(plane->state, plane->fb);
      
      inserted after the fb update has logically completed at the end of
      ->set_config (or ->set_base/mode_set if using the crtc helpers),
      ->page_flip, ->update_plane or any other entry point which updates
      plane->fb.
      
      v2: Update kerneldoc - copypasta fail.
      
      v3: Fix spelling in the commit message (Sean).
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      321ebf04