1. 01 Dec, 2014 2 commits
  2. 27 Nov, 2014 7 commits
    • Rob Clark's avatar
      drm/atomic: clear plane's CRTC and FB when shutting down · e5b5341c
      Rob Clark authored
      Otherwise we'd still end up w/ the plane attached to the CRTC, and
      seemingly active, but without an FB.  Which ends up going *boom*
      in the drivers.
      
      Slightly modified version of Daniel's irc suggestion.
      
      Note that the big problem isn't drivers going *boom* here (since we
      already have the situation of planes being left enabled when the crtc
      goes down). The real issue is that the core assumes the primary plane
      always goes down when calling ->set_config with a NULL mode. Ignoring
      that assumption leads to the legacy state pointers plane->fb/crtc
      getting out of sync with atomic, and that then leads to the subsequent
      *boom* all over the place.
      
      CC: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      [danvet: Drop my opinion of what's going sidewides here into the
      commit message as a note.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e5b5341c
    • Daniel Vetter's avatar
      drm: Handle atomic state properly in kms getfoo ioctl · abd69c55
      Daniel Vetter authored
      So the problem with async commit (especially async modeset commit) is
      that the legacy pointers only get updated after the point of no
      return, in the async part of the modeset sequence. At least as
      implemented by the current helper functions. This is done in the
      set_routing_links function in drm_atomic_helper.c.
      
      Which also means that access isn't protected by locks but only
      coordinated by synchronizing with async workers. No problem thus far,
      until we lock at the getconnector/encoder ioctls.
      
      So fix this up by adding special cases for atomic drivers: For those
      we need to look at state objects. Unfortunately digging out the
      correct encoder->crtc link is a bit of work, so wrap this up in a
      helper function.
      
      Moving the assignments of connector->encoder and encoder->crtc earlier
      isn't a good idea because the point of the atomic helpers is that we
      stage the state updates. That way the disable functions can still
      inspect the links and rely upon them.
      
      v2: Extract full encoder->crtc lookup into helper (Rob).
      
      v3: Extract drm_connector_get_encoder too since - we need to always
      return state->best_encoder when there is a state otherwise we might
      return stale data if there's a pending async disable (and chase
      unlocked pointers, too). Same issue with encoder_get_crtc but there
      it's a bit more tricky to handle.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Lightly-Tested-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      abd69c55
    • Rob Clark's avatar
      drm: use mode_object_find helpers · 933f622f
      Rob Clark authored
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      933f622f
    • Rob Clark's avatar
      drm: fix indentation · 417009fb
      Rob Clark authored
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      417009fb
    • Rob Clark's avatar
      93b02beb
    • Rob Clark's avatar
      drm/atomic: add plane iterator macros · dd275956
      Rob Clark authored
      Add helper macros to iterate the current, or incoming set of planes
      attached to a crtc.  These helpers are only available for drivers
      converted to use atomic-helpers.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      [danvet: Squash in fixup from Rob to move the planemask iterator to
      drm_crtc.h and document it. That one is needed by the atomic ioctl so
      can't be in a helper library.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dd275956
    • 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
  3. 25 Nov, 2014 10 commits
  4. 21 Nov, 2014 21 commits