1. 30 Mar, 2016 2 commits
  2. 29 Mar, 2016 3 commits
  3. 21 Mar, 2016 2 commits
  4. 20 Mar, 2016 1 commit
  5. 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
  6. 15 Mar, 2016 2 commits
  7. 13 Mar, 2016 2 commits
  8. 10 Mar, 2016 1 commit
  9. 08 Mar, 2016 6 commits
  10. 04 Mar, 2016 17 commits
  11. 29 Feb, 2016 1 commit
  12. 26 Feb, 2016 2 commits
    • Dave Airlie's avatar
      Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next · 44ab4042
      Dave Airlie authored
      As previously discussed, this is my first pull request for the DCU DRM
      driver along with the change in MAINTAINERS.
      https://lkml.org/lkml/2016/1/7/26
      
      The pull contains some code cleanup changes (e.g. removing all error
      handling for the regmap calls) and several fixes.
      
      * 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu:
        drm/fsl-dcu: fix register initialization
        drm/fsl-dcu: use mode flags for hsync/vsync polarity
        drm/fsl-dcu: fix alpha blending
        drm/fsl-dcu: mask all interrupts on initialization
        drm/fsl-dcu: handle initialization errors properly
        drm/fsl-dcu: avoid memory leak on errors
        drm/fsl-dcu: remove regmap return value checks
        drm/fsl-dcu: specify volatile registers
        drm: fsl-dcu: Fix no fb check bug
        MAINTAINERS: update for Freescale DCU DRM driver
      44ab4042
    • Stefan Agner's avatar
      drm/fsl-dcu: fix register initialization · f76b9873
      Stefan Agner authored
      The layer enumeration start with 0 (0-15 for LS1021a and 0-63 for
      Vybrid) whereas the register enumeration start from 1 (1-10 for
      LS1021a and 1-9 for Vybrid). The loop started off from 0 for both
      iterations and initialized the number of layers inclusive, which
      is one layer too many.
      
      All extensively written registers seem to be unassigned, it seems
      that the write to those registers did not do any harm in practice.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      f76b9873