1. 15 11月, 2014 2 次提交
  2. 13 11月, 2014 26 次提交
  3. 12 11月, 2014 3 次提交
    • D
      drm: More specific locking for get* ioctls · fcf93f69
      Daniel Vetter 提交于
      Motivated by the per-plane locking I've gone through all the get*
      ioctls and reduced the locking to the bare minimum required.
      
      v2: Rebase and make it compile ...
      
      v3: Review from Sean:
      - Simplify return handling in getplane_res.
      - Add a comment to getplane_res that the plane list is invariant and
        can be walked locklessly.
      
      v4: Actually git add.
      
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      fcf93f69
    • D
      drm: Per-plane locking · 4d02e2de
      Daniel Vetter 提交于
      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: NDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      4d02e2de
    • R
      drm: export atomic wait_for_vblanks helper (v2) · 5ee3229c
      Rob Clark 提交于
      v1: original
      v2: danvet's kerneldoc nitpicks
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5ee3229c
  4. 10 11月, 2014 1 次提交
  5. 07 11月, 2014 8 次提交
    • D
      drm: drop README.drm, ancient scrolls · 5fa2704e
      Dave Airlie 提交于
      This stuff is ancient, we have docs now in the kernel,
      lets just drop it.
      
      Pointed out by Glenn
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5fa2704e
    • D
      drm/atomic: Refcounting for plane_state->fb · 321ebf04
      Daniel Vetter 提交于
      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: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      321ebf04
    • D
      drm: Docbook integration and over sections for all the new helpers · 3150c7d0
      Daniel Vetter 提交于
      In all cases the text requires that new drivers are converted to the
      atomic interfaces.
      
      v2: Add overview for state handling.
      
      v3: Review from Sean: Some spelling fixes and drop the misguided
      hunk to remove rgba8888 from the plane helpers compat list.
      
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3150c7d0
    • D
      drm/atomic-helpers: functions for state duplicate/destroy/reset · d461701c
      Daniel Vetter 提交于
      The atomic users and helpers assume that there is always a obj->state
      structure around. Which means drivers need to somehow create that at
      driver load time. Also it should obviously reset hardware state, so
      needs to be reset upon resume.
      
      Finally the destroy/duplicate_state functions are an awful lot of
      boilerplate if the driver doesn't need anything beyond the default
      state objects.
      
      So add helper functions for all of this.
      
      v2: Somehow the plane/connector versions got lost in the first
      version.
      
      v3: Add kerneldoc.
      
      v4: Make duplicate_state functions a bit more robust, which is useful
      for debugging state tracking issues when transitioning to atomic.
      
      v5: Clear temporary variables in the crtc state when duplicating it,
      like ->mode_changed or ->planes_changed. If we don't do this stale
      values for these might pollute the next atomic modeset.
      
      v6: Also clear crtc_state->event in case the driver didn't (yet) clear
      this out.
      
      v7: Split out wrong squashed commit. Also improve the kerneldoc to
      mention that obj->state can be NULL and when.  Both suggested by
      Daniel Thompson.
      
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d461701c
    • D
      drm/atomic-helper: implement ->page_flip · 8bc0f312
      Daniel Vetter 提交于
      Currently there is no way to implement async flips using atomic, that
      essentially requires us to be able to cancel pending requests
      mid-flight.
      
      To be able to do that (and I guess we want this since vblank synced
      updates which opportunistically cancel still pending updates seem to be
      wanted) we'd need to add a mandatory cancellation mode. Depending upon
      the exact semantics we decide upon that could mean that userspace will
      not get completion events, or will get them all stacked up.
      
      So reject async updates for now. Also async updates usually means not
      vblank synced at all, and I guess for drivers which want to support
      this they should simply add a special pageflip handler (since usually
      you need a special flip cmd to achieve this). That kind of async flip
      is pretty much exclusively just used for games and benchmarks where
      dropping just one frame means you'll get a headshot or something bad
      like that ... And so slight amounts of tearing is acceptable.
      
      v2: Fixup kerneldoc, reported by Paulo.
      
      v3: Use the set_crtc_for_plane function to assign the crtc, since
      otherwise the book-keeping is off.
      
      v4: Update crtc->primary->fb since ->page_flip is the only driver
      callback where the core won't do this itself. We might want to fix
      this inconsistency eventually.
      
      v5: Use set_crtc_for_connector as suggested by Sean.
      
      v6: Daniel Thompson noticed that my error handling is inconsistent
      and that in a few cases I didn't handle fatal errors (i.e. not
      -EDEADLK). Fix this by consolidate the ww mutex backoff handling
      into one check in the fail: block and flatten the error control
      flow everywhere else.
      
      v7: Fix spelling mistake in the commit message (Sean).
      
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8bc0f312
    • D
      drm/atomic-helpers: document how to implement async commit · e8c833a7
      Daniel Vetter 提交于
      No helper function to do it all yet provided since no driver has
      support for driver core fences yet. Which we'd need to make the
      implementation really generic.
      
      v2: Clarify async howto a bit per the discussion With Rob Clark.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e8c833a7
    • D
      drm/atomic: Integrate fence support · e2330f07
      Daniel Vetter 提交于
      This patch is for enabling async commits. It replaces an earlier
      approach which added an async boolean paramter to the ->prepare_fb
      callbacks. The idea is that prepare_fb picks up the right fence to
      synchronize against, which is then used by the synchronous commit
      helper. For async commits drivers can either register a callback to
      the fence or simply do the synchronous wait in their async work queue.
      
      v2: Remove unused variable.
      
      v3: Only wait for fences after the point of no return in the part
      of the commit function which can be run asynchronously. This is after
      the atomic state has been swapped in, hence now check
      plane->state->fence.
      
      Also add a WARN_ON to make sure we don't try to wait on a fence when
      there's no fb, just as a sanity check.
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      e2330f07
    • D
      drm/atomic-helper: implementatations for legacy interfaces · 042652ed
      Daniel Vetter 提交于
      Well, except page_flip since that requires async commit, which isn't
      there yet.
      
      For the functions which changes planes there's a bit of trickery
      involved to keep the fb refcounting working. But otherwise fairly
      straight-forward atomic updates.
      
      The property setting functions are still a bit incomplete. Once we
      have generic properties (e.g. rotation, but also all the properties
      needed by the atomic ioctl) we need to filter those out and parse them
      in the helper. Preferrably with the same function as used by the real
      atomic ioctl implementation.
      
      v2: Fixup kerneldoc, reported by Paulo.
      
      v3: Add missing EXPORT_SYMBOL.
      
      v4: We need to look at the crtc of the modeset, not some random
      leftover one from a previous loop when udpating the connector->crtc
      routing. Also push some local variables into inner loops to avoid
      these kinds of bugs.
      
      v5: Adjust semantics - drivers now own the atomic state upon
      successfully synchronous commit.
      
      v6: Use the set_crtc_for_plane function to assign the crtc, since
      otherwise the book-keeping is off.
      
      v7:
      - Improve comments.
      - Filter out the crtc of the ->set_config call when recomputing
        crtc_state->enabled: We should compute the same state, but not doing
        so will give us a good chance to catch bugs and inconsistencies -
        the atomic helper's atomic_check function re-validates this again.
      - Fix the set_config implementation logic when disabling the crtc: We
        still need to update the output routing to disable all the
        connectors properly in the state. Caught by the atomic_check
        functions, so at least that part worked ;-) Also add some WARN_ONs
        to ensure ->set_config preconditions all apply.
      
      v8: Fixup an embarrassing h/vdisplay mixup.
      
      v9: Shuffled bad squash to the right patch, spotted by Daniel
      
      v10: Use set_crtc_for_connector as suggested by Sean.
      
      v11: Daniel Thompson noticed that my error handling is inconsistent
      and that in a few cases I didn't handle fatal errors (i.e. not
      -EDEADLK). Fix this by consolidate the ww mutex backoff handling
      into one check in the fail: block and flatten the error control
      flow everywhere else.
      
      v12: Review and discussion with Sean:
      - One spelling fix.
      - Correctly skip the crtc from the set_config set when recomputing
        ->enable state. That should allow us to catch any bugs in higher
        levels in computing that state (which is supplied to the
        ->set_config implementation). I've screwed this up and Sean spotted
        that the current code is pointless.
      
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      042652ed