1. 18 Jul, 2016 1 commit
  2. 13 Jul, 2016 1 commit
  3. 20 Jun, 2016 3 commits
  4. 03 Jun, 2016 1 commit
  5. 02 Jun, 2016 3 commits
  6. 31 May, 2016 2 commits
  7. 29 Apr, 2016 1 commit
  8. 21 Mar, 2016 1 commit
    • Daniel Vetter's avatar
      dma-buf: Update docs for SYNC ioctl · 87e332d5
      Daniel Vetter authored
      Just a bit of wording polish plus mentioning that it can fail and must
      be restarted.
      
      Requested by Sumit.
      
      v2: Fix them typos (Hans).
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tiago Vignatti <tiago.vignatti@intel.com>
      Cc: Stéphane Marchesin <marcheu@chromium.org>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      CC: linux-media@vger.kernel.org
      Cc: dri-devel@lists.freedesktop.org
      Cc: linaro-mm-sig@lists.linaro.org
      Cc: intel-gfx@lists.freedesktop.org
      Cc: devel@driverdev.osuosl.org
      Cc: Hans Verkuil <hverkuil@xs4all.nl>
      Acked-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      87e332d5
  9. 19 Mar, 2016 1 commit
    • Chris Wilson's avatar
      dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access() · 18b862dc
      Chris Wilson authored
      Drivers, especially i915.ko, can fail during the initial migration of a
      dma-buf for CPU access. However, the error code from the driver was not
      being propagated back to ioctl and so userspace was blissfully ignorant
      of the failure. Rendering corruption ensues.
      
      Whilst fixing the ioctl to return the error code from
      dma_buf_start_cpu_access(), also do the same for
      dma_buf_end_cpu_access().  For most drivers, dma_buf_end_cpu_access()
      cannot fail. i915.ko however, as most drivers would, wants to avoid being
      uninterruptible (as would be required to guarrantee no failure when
      flushing the buffer to the device). As userspace already has to handle
      errors from the SYNC_IOCTL, take advantage of this to be able to restart
      the syscall across signals.
      
      This fixes a coherency issue for i915.ko as well as reducing the
      uninterruptible hold upon its BKL, the struct_mutex.
      
      Fixes commit c11e391d
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Feb 11 20:04:51 2016 -0200
      
          dma-buf: Add ioctls to allow userspace to flush
      
      Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
      Testcase: igt/prime_mmap_coherency/ioctl-errors
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tiago Vignatti <tiago.vignatti@intel.com>
      Cc: Stéphane Marchesin <marcheu@chromium.org>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      CC: linux-media@vger.kernel.org
      Cc: dri-devel@lists.freedesktop.org
      Cc: linaro-mm-sig@lists.linaro.org
      Cc: intel-gfx@lists.freedesktop.org
      Cc: devel@driverdev.osuosl.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
      18b862dc
  10. 12 Feb, 2016 1 commit
    • Daniel Vetter's avatar
      dma-buf: Add ioctls to allow userspace to flush · c11e391d
      Daniel Vetter authored
      The userspace might need some sort of cache coherency management e.g. when CPU
      and GPU domains are being accessed through dma-buf at the same time. To
      circumvent this problem there are begin/end coherency markers, that forward
      directly to existing dma-buf device drivers vfunc hooks. Userspace can make use
      of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence would be
      used like following:
           - mmap dma-buf fd
           - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
             to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
             want (with the new data being consumed by the GPU or say scanout device)
           - munmap once you don't need the buffer any more
      
      v2 (Tiago): Fix header file type names (u64 -> __u64)
      v3 (Tiago): Add documentation. Use enum dma_buf_sync_flags to the begin/end
      dma-buf functions. Check for overflows in start/length.
      v4 (Tiago): use 2d regions for sync.
      v5 (Tiago): forget about 2d regions (v4); use _IOW in DMA_BUF_IOCTL_SYNC and
      remove range information from struct dma_buf_sync.
      v6 (Tiago): use __u64 structured padded flags instead enum. Adjust
      documentation about the recommendation on using sync ioctls.
      v7 (Tiago): Alex' nit on flags definition and being even more wording in the
      doc about sync usage.
      v9 (Tiago): remove useless is_dma_buf_file check. Fix sync.flags conditionals
      and its mask order check. Add <linux/types.h> include in dma-buf.h.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Reviewed-by: default avatarStéphane Marchesin <marcheu@chromium.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarTiago Vignatti <tiago.vignatti@intel.com>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1455228291-29640-1-git-send-email-tiago.vignatti@intel.com
      c11e391d
  11. 09 Feb, 2016 1 commit
  12. 29 Oct, 2015 1 commit
  13. 20 May, 2015 1 commit
  14. 13 May, 2015 1 commit
  15. 21 Apr, 2015 1 commit
  16. 22 Jan, 2015 1 commit
  17. 21 Jan, 2015 2 commits
  18. 03 Nov, 2014 1 commit
  19. 09 Oct, 2014 1 commit
  20. 28 Aug, 2014 1 commit
  21. 08 Jul, 2014 7 commits
    • Maarten Lankhorst's avatar
      reservation: add suppport for read-only access using rcu · 3c3b177a
      Maarten Lankhorst authored
      This adds some extra functions to deal with rcu.
      
      reservation_object_get_fences_rcu() will obtain the list of shared
      and exclusive fences without obtaining the ww_mutex.
      
      reservation_object_wait_timeout_rcu() will wait on all fences of the
      reservation_object, without obtaining the ww_mutex.
      
      reservation_object_test_signaled_rcu() will test if all fences of the
      reservation_object are signaled without using the ww_mutex.
      
      reservation_object_get_excl and reservation_object_get_list require
      the reservation object to be held, updating requires
      write_seqcount_begin/end. If only the exclusive fence is needed,
      rcu_dereference followed by fence_get_rcu can be used, if the shared
      fences are needed it's recommended to use the supplied functions.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Acked-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Reviewed-By: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c3b177a
    • Maarten Lankhorst's avatar
      reservation: update api and add some helpers · 04a5faa8
      Maarten Lankhorst authored
      Move the list of shared fences to a struct, and return it in
      reservation_object_get_list().
      Add reservation_object_get_excl to get the exclusive fence.
      
      Add reservation_object_reserve_shared(), which reserves space
      in the reservation_object for 1 more shared fence.
      
      reservation_object_add_shared_fence() and
      reservation_object_add_excl_fence() are used to assign a new
      fence to a reservation_object pointer, to complete a reservation.
      
      Changes since v1:
      - Add reservation_object_get_excl, reorder code a bit.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Acked-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04a5faa8
    • Maarten Lankhorst's avatar
      dma-buf: add poll support, v3 · 9b495a58
      Maarten Lankhorst authored
      Thanks to Fengguang Wu for spotting a missing static cast.
      
      v2:
      - Kill unused variable need_shared.
      v3:
      - Clarify the BUG() in dma_buf_release some more. (Rob Clark)
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Acked-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b495a58
    • Maarten Lankhorst's avatar
      dma-buf: use reservation objects · 3aac4502
      Maarten Lankhorst authored
      This allows reservation objects to be used in dma-buf. it's required
      for implementing polling support on the fences that belong to a dma-buf.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com> #drivers/media/v4l2-core/
      Acked-by: Thomas Hellstrom <thellstrom@vmware.com> #drivers/gpu/drm/ttm
      Acked-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net> #drivers/gpu/drm/armada/
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3aac4502
    • Maarten Lankhorst's avatar
      seqno-fence: Hardware dma-buf implementation of fencing (v6) · 606b23ad
      Maarten Lankhorst authored
      This type of fence can be used with hardware synchronization for simple
      hardware that can block execution until the condition
      (dma_buf[offset] - value) >= 0 has been met when WAIT_GEQUAL is used,
      or (dma_buf[offset] != 0) has been met when WAIT_NONZERO is set.
      
      A software fallback still has to be provided in case the fence is used
      with a device that doesn't support this mechanism. It is useful to expose
      this for graphics cards that have an op to support this.
      
      Some cards like i915 can export those, but don't have an option to wait,
      so they need the software fallback.
      
      I extended the original patch by Rob Clark.
      
      v1: Original
      v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
          not much was left of the file. Lots of documentation added.
      v3: Use fence_ops instead of custom callbacks. Moved to own file
          to avoid circular dependency between dma-buf.h and fence.h
      v4: Add spinlock pointer to seqno_fence_init
      v5: Add condition member to allow wait for != 0.
          Fix small style errors pointed out by checkpatch.
      v6: Move to a separate file. Fix up api changes in fences.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Acked-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Reviewed-by: Rob Clark <robdclark@gmail.com> #v4
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      606b23ad
    • Maarten Lankhorst's avatar
      fence: dma-buf cross-device synchronization (v18) · e941759c
      Maarten Lankhorst authored
      A fence can be attached to a buffer which is being filled or consumed
      by hw, to allow userspace to pass the buffer without waiting to another
      device.  For example, userspace can call page_flip ioctl to display the
      next frame of graphics after kicking the GPU but while the GPU is still
      rendering.  The display device sharing the buffer with the GPU would
      attach a callback to get notified when the GPU's rendering-complete IRQ
      fires, to update the scan-out address of the display, without having to
      wake up userspace.
      
      A driver must allocate a fence context for each execution ring that can
      run in parallel. The function for this takes an argument with how many
      contexts to allocate:
        + fence_context_alloc()
      
      A fence is transient, one-shot deal.  It is allocated and attached
      to one or more dma-buf's.  When the one that attached it is done, with
      the pending operation, it can signal the fence:
        + fence_signal()
      
      To have a rough approximation whether a fence is fired, call:
        + fence_is_signaled()
      
      The dma-buf-mgr handles tracking, and waiting on, the fences associated
      with a dma-buf.
      
      The one pending on the fence can add an async callback:
        + fence_add_callback()
      
      The callback can optionally be cancelled with:
        + fence_remove_callback()
      
      To wait synchronously, optionally with a timeout:
        + fence_wait()
        + fence_wait_timeout()
      
      When emitting a fence, call:
        + trace_fence_emit()
      
      To annotate that a fence is blocking on another fence, call:
        + trace_fence_annotate_wait_on(fence, on_fence)
      
      A default software-only implementation is provided, which can be used
      by drivers attaching a fence to a buffer when they have no other means
      for hw sync.  But a memory backed fence is also envisioned, because it
      is common that GPU's can write to, or poll on some memory location for
      synchronization.  For example:
      
        fence = custom_get_fence(...);
        if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
          dma_buf *fence_buf = seqno_fence->sync_buf;
          get_dma_buf(fence_buf);
      
          ... tell the hw the memory location to wait ...
          custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
        } else {
          /* fall-back to sw sync * /
          fence_add_callback(fence, my_cb);
        }
      
      On SoC platforms, if some other hw mechanism is provided for synchronizing
      between IP blocks, it could be supported as an alternate implementation
      with it's own fence ops in a similar way.
      
      enable_signaling callback is used to provide sw signaling in case a cpu
      waiter is requested or no compatible hardware signaling could be used.
      
      The intention is to provide a userspace interface (presumably via eventfd)
      later, to be used in conjunction with dma-buf's mmap support for sw access
      to buffers (or for userspace apps that would prefer to do their own
      synchronization).
      
      v1: Original
      v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
          that dma-fence didn't need to care about the sw->hw signaling path
          (it can be handled same as sw->sw case), and therefore the fence->ops
          can be simplified and more handled in the core.  So remove the signal,
          add_callback, cancel_callback, and wait ops, and replace with a simple
          enable_signaling() op which can be used to inform a fence supporting
          hw->hw signaling that one or more devices which do not support hw
          signaling are waiting (and therefore it should enable an irq or do
          whatever is necessary in order that the CPU is notified when the
          fence is passed).
      v3: Fix locking fail in attach_fence() and get_fence()
      v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
          we decided that we need to be able to attach one fence to N dma-buf's,
          so using the list_head in dma-fence struct would be problematic.
      v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
      v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
          about checking if fence fired or not. This is broken by design.
          waitqueue_active during destruction is now fatal, since the signaller
          should be holding a reference in enable_signalling until it signalled
          the fence. Pass the original dma_fence_cb along, and call __remove_wait
          in the dma_fence_callback handler, so that no cleanup needs to be
          performed.
      v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
          fence wasn't signaled yet, for example for hardware fences that may
          choose to signal blindly.
      v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
          header and fixed include mess. dma-fence.h now includes dma-buf.h
          All members are now initialized, so kmalloc can be used for
          allocating a dma-fence. More documentation added.
      v9: Change compiler bitfields to flags, change return type of
          enable_signaling to bool. Rework dma_fence_wait. Added
          dma_fence_is_signaled and dma_fence_wait_timeout.
          s/dma// and change exports to non GPL. Added fence_is_signaled and
          fence_enable_sw_signaling calls, add ability to override default
          wait operation.
      v10: remove event_queue, use a custom list, export try_to_wake_up from
          scheduler. Remove fence lock and use a global spinlock instead,
          this should hopefully remove all the locking headaches I was having
          on trying to implement this. enable_signaling is called with this
          lock held.
      v11:
          Use atomic ops for flags, lifting the need for some spin_lock_irqsaves.
          However I kept the guarantee that after fence_signal returns, it is
          guaranteed that enable_signaling has either been called to completion,
          or will not be called any more.
      
          Add contexts and seqno to base fence implementation. This allows you
          to wait for less fences, by testing for seqno + signaled, and then only
          wait on the later fence.
      
          Add FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
          An CONFIG_DEBUG_FENCE will be added to turn off the FENCE_TRACE
          spam, and another runtime option can turn it off at runtime.
      v12:
          Add CONFIG_FENCE_TRACE. Add missing documentation for the fence->context
          and fence->seqno members.
      v13:
          Fixup CONFIG_FENCE_TRACE kconfig description.
          Move fence_context_alloc to fence.
          Simplify fence_later.
          Kill priv member to fence_cb.
      v14:
          Remove priv argument from fence_add_callback, oops!
      v15:
          Remove priv from documentation.
          Explicitly include linux/atomic.h.
      v16:
          Add trace events.
          Import changes required by android syncpoints.
      v17:
          Use wake_up_state instead of try_to_wake_up. (Colin Cross)
          Fix up commit description for seqno_fence. (Rob Clark)
      v18:
          Rename release_fence to fence_release.
          Move to drivers/dma-buf/.
          Rename __fence_is_signaled and __fence_signal to *_locked.
          Rename __fence_init to fence_init.
          Make fence_default_wait return a signed long, and fix wait ops too.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Signed-off-by: Thierry Reding <thierry.reding@gmail.com> #use smp_mb__before_atomic()
      Acked-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e941759c
    • Maarten Lankhorst's avatar