1. 03 7月, 2017 1 次提交
    • G
      drm/atomic: initial support for asynchronous plane update · fef9df8b
      Gustavo Padovan 提交于
      In some cases, like cursor updates, it is interesting to update the
      plane in an asynchronous fashion to avoid big delays. The current queued
      update could be still waiting for a fence to signal and thus block any
      subsequent update until its scan out. In cases like this if we update the
      cursor synchronously through the atomic API it will cause significant
      delays that would even be noticed by the final user.
      
      This patch creates a fast path to jump ahead the current queued state and
      do single planes updates without going through all atomic steps in
      drm_atomic_helper_commit(). We take this path for legacy cursor updates.
      
      For now only single plane updates are supported, but we plan to support
      multiple planes updates and async PageFlips through this interface as well
      in the near future.
      
      v6:	- move check code to drm_atomic_helper.c (Daniel Vetter)
      
      v5:
      	- improve comments (Eric Anholt)
      
      v4:
      	- fix state->crtc NULL check (Archit Taneja)
      
      v3:
      	- fix iteration on the wrong crtc state
      	- put back code to forbid updates if there is a queued update for
      	the same plane (Ville Syrjälä)
      	- move size checks back to drivers (Ville Syrjälä)
      	- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)
      
      v2:
      	- allow updates even if there is a queued update for the same
      	plane.
              - fixes on the documentation (Emil Velikov)
              - unconditionally call ->atomic_async_update (Emil Velikov)
              - check for ->atomic_async_update earlier (Daniel Vetter)
              - make ->atomic_async_check() the last step (Daniel Vetter)
              - add ASYNC_UPDATE flag (Eric Anholt)
              - update state in core after ->atomic_async_update (Eric Anholt)
      	- update docs (Eric Anholt)
      
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Eric Anholt <eric@anholt.net>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.com>
      Reviewed-by: Archit Taneja <architt@codeaurora.org> (v5)
      Acked-by: Eric Anholt <eric@anholt.net> (v5)
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170630180322.29007-2-gustavo@padovan.org
      fef9df8b
  2. 30 6月, 2017 1 次提交
  3. 28 6月, 2017 1 次提交
    • D
      drm/vblank: Unexport drm_vblank_cleanup · b4164d66
      Daniel Vetter 提交于
      There's no reason for drivers to call this, and all the ones I've
      removed looked very fishy:
      - Proper quiescenting of the vblank machinery should be done by
        calling drm_crtc_vblank_off(), which is best done by shutting down
        the entire display engine with drm_atomic_helper_shutdown.
      
      - Releasing of allocated memory is done by the core already, it calls
        drm_vblank_cleanup as a fallback.
      
      - drm_vblank_cleanup also has checks for drivers which forget to clean
        up vblank interrupts.
      
      This essentially reverts
      
      commit e77cef9c
      Author: Jerome Glisse <jglisse@redhat.com>
      Date:   Thu Jan 7 15:39:13 2010 +0100
      
          drm: Avoid calling vblank function is vblank wasn't initialized
      
      which was done to fix a bug in radeon code with msi interrupts:
      
      commit 003e69f9
      Author: Jerome Glisse <jglisse@redhat.com>
      Date:   Thu Jan 7 15:39:14 2010 +0100
      
          drm/radeon/kms: Don't try to enable IRQ if we have no handler installed
      
      Afaict from digging around in old code, this was needed to avoid
      blowing up in the ums fallback, and has stopped serving it's purpose
      long ago - if irq init fails, the driver fails to load, and there's
      really no way to blow up anymore.
      
      Long story short, this was most likely a small ums compat/fallback
      hack that became a thing of it's own and got cargo-cult duplicated all
      over the drm codebase for essentially no gain at all.
      
      v2: Mention that for drivers with a ->release callback cleanup is
      handled by drm_dev_fini() (Thierry).
      
      Cc: Thierry Reding <treding@nvidia.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170626161949.25629-2-daniel.vetter@ffwll.ch
      b4164d66
  4. 22 6月, 2017 1 次提交
  5. 20 6月, 2017 6 次提交
  6. 15 6月, 2017 1 次提交
  7. 14 6月, 2017 1 次提交
    • D
      drm: introduce sync objects (v4) · e9083420
      Dave Airlie 提交于
      Sync objects are new toplevel drm object, that contain a
      pointer to a fence. This fence can be updated via command
      submission ioctls via drivers.
      
      There is also a generic wait obj API modelled on the vulkan
      wait API (with code modelled on some amdgpu code).
      
      These objects can be converted to an opaque fd that can be
      passes between processes.
      
      v2: rename reference/unreference to put/get (Chris)
      fix leaked reference (David Zhou)
      drop mutex in favour of cmpxchg (Chris)
      v3: cleanups from danvet, rebase on drm_fops rename
      check fd_flags is 0 in ioctls.
      v4: export find/free, change replace fence to take a
      syncobj. In order to support lookup first, replace
      later semantics which seem in the end to be cleaner.
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e9083420
  8. 10 6月, 2017 3 次提交
  9. 09 6月, 2017 1 次提交
  10. 07 6月, 2017 2 次提交
  11. 05 6月, 2017 2 次提交
  12. 02 6月, 2017 1 次提交
  13. 01 6月, 2017 2 次提交
  14. 31 5月, 2017 3 次提交
  15. 30 5月, 2017 2 次提交
  16. 29 5月, 2017 2 次提交
  17. 26 5月, 2017 2 次提交
  18. 23 5月, 2017 3 次提交
  19. 22 5月, 2017 1 次提交
  20. 18 5月, 2017 3 次提交
  21. 16 5月, 2017 1 次提交