1. 19 Jun, 2019 1 commit
  2. 14 Jun, 2019 3 commits
  3. 22 May, 2019 1 commit
  4. 24 Apr, 2019 2 commits
  5. 24 Dec, 2018 1 commit
  6. 10 Aug, 2018 1 commit
  7. 20 Jun, 2018 2 commits
  8. 01 Jun, 2018 1 commit
  9. 11 Feb, 2018 1 commit
    • Linus Torvalds's avatar
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds authored
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
      with de-mangling cleanups yet to come.
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 28 Nov, 2017 1 commit
  11. 27 Nov, 2017 1 commit
  12. 23 Nov, 2017 1 commit
  13. 02 Nov, 2017 1 commit
  14. 20 Sep, 2017 1 commit
  15. 08 May, 2017 3 commits
  16. 20 Apr, 2017 1 commit
  17. 03 Apr, 2017 1 commit
  18. 31 Mar, 2017 1 commit
  19. 27 Feb, 2017 1 commit
  20. 30 Dec, 2016 2 commits
  21. 13 Dec, 2016 3 commits
  22. 25 Oct, 2016 1 commit
    • Chris Wilson's avatar
      dma-buf: Rename struct fence to dma_fence · f54d1867
      Chris Wilson authored
      I plan to usurp the short name of struct fence for a core kernel struct,
      and so I need to rename the specialised fence/timeline for DMA
      operations to make room.
      A consensus was reached in
      that making clear this fence applies to DMA operations was a good thing.
      Since then the patch has grown a bit as usage increases, so hopefully it
      remains a good thing!
      (v2...: rebase, rerun spatch)
      v3: Compile on msm, spotted a manual fixup that I broke.
      v4: Try again for msm, sorry Daniel
      coccinelle script:
      - struct fence
      + struct dma_fence
      - struct fence_ops
      + struct dma_fence_ops
      - struct fence_cb
      + struct dma_fence_cb
      - struct fence_array
      + struct dma_fence_array
      - enum fence_flag_bits
      + enum dma_fence_flag_bits
      - fence_init
      + dma_fence_init
      - fence_release
      + dma_fence_release
      - fence_free
      + dma_fence_free
      - fence_get
      + dma_fence_get
      - fence_get_rcu
      + dma_fence_get_rcu
      - fence_put
      + dma_fence_put
      - fence_signal
      + dma_fence_signal
      - fence_signal_locked
      + dma_fence_signal_locked
      - fence_default_wait
      + dma_fence_default_wait
      - fence_add_callback
      + dma_fence_add_callback
      - fence_remove_callback
      + dma_fence_remove_callback
      - fence_enable_sw_signaling
      + dma_fence_enable_sw_signaling
      - fence_is_signaled_locked
      + dma_fence_is_signaled_locked
      - fence_is_signaled
      + dma_fence_is_signaled
      - fence_is_later
      + dma_fence_is_later
      - fence_later
      + dma_fence_later
      - fence_wait_timeout
      + dma_fence_wait_timeout
      - fence_wait_any_timeout
      + dma_fence_wait_any_timeout
      - fence_wait
      + dma_fence_wait
      - fence_context_alloc
      + dma_fence_context_alloc
      - fence_array_create
      + dma_fence_array_create
      - to_fence_array
      + to_dma_fence_array
      - fence_is_array
      + dma_fence_is_array
      - trace_fence_emit
      + trace_dma_fence_emit
      - FENCE_WARN
      - FENCE_ERR
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Gustavo Padovan's avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Acked-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk
  23. 16 Aug, 2016 1 commit
  24. 18 Jul, 2016 1 commit
  25. 20 Jun, 2016 3 commits
  26. 31 May, 2016 1 commit
  27. 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>
  28. 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
  29. 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