1. 20 Mar, 2016 1 commit
  2. 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
  3. 15 Mar, 2016 2 commits
  4. 13 Mar, 2016 2 commits
  5. 10 Mar, 2016 1 commit
  6. 08 Mar, 2016 6 commits
  7. 04 Mar, 2016 17 commits
  8. 29 Feb, 2016 1 commit
  9. 26 Feb, 2016 9 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
    • Stefan Agner's avatar
      drm/fsl-dcu: use mode flags for hsync/vsync polarity · 4bc390c6
      Stefan Agner authored
      The current default configuration is as follows:
      - Invert VSYNC signal (active LOW)
      - Invert HSYNC signal (active LOW)
      
      The mode flags allow to specify the required polarity per
      mode. Furthermore, none of the current driver settings is
      actually a standard polarity.
      
      This patch applies the current driver default polarities as
      explicit flags to the display which has been introduced with
      the driver (NEC WQVGA "nec,nl4827hc19-05b"). The driver now
      also parses the flags field and applies the configuration
      accordingly, by using the following values as standard
      polarities: (e.g. when no flags are specified):
      - VSYNC signal not inverted (active HIGH)
      - HSYNC signal not inverted (active HIGH)
      Acked-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      4bc390c6
    • Stefan Agner's avatar
      drm/fsl-dcu: fix alpha blending · 69855819
      Stefan Agner authored
      Fix alpha blending by enabling alpha blending for the whole frame if
      a color mode with alpha channel is selected (DRM_FORMAT_ARGB*). Also
      support color modes without alpha channel (DRM_FORMAT_XRGB*) by just
      not enabling alpha blending on layer level.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      69855819
    • Stefan Agner's avatar
      drm/fsl-dcu: mask all interrupts on initialization · 638c93f6
      Stefan Agner authored
      The state of the interrupt mask register on initialization is
      unknown, e.g. U-Boot could already used the DCU. So depending on
      the boot loader, the outcome of the interrupt mask register could
      be different. A defined state is much more preferable. Also, there
      is no value in keeping interrupts enabled which we don't need.
      Therefor, mask all interrupts on initialization.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      638c93f6
    • Stefan Agner's avatar
      drm/fsl-dcu: handle initialization errors properly · 7566e247
      Stefan Agner authored
      If initialization fails (e.g. due to missing panel node or deferred
      probe) make sure to roll-back all operations and return the error
      code.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      7566e247
    • Stefan Agner's avatar
      drm/fsl-dcu: avoid memory leak on errors · 72cc05a5
      Stefan Agner authored
      Improve error handling during CRTC initialization. Especially avoid
      memory leaks in the primary plane initialization error path.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      72cc05a5
    • Stefan Agner's avatar
      drm/fsl-dcu: remove regmap return value checks · e291d298
      Stefan Agner authored
      It is not common to do regmap return value checks, especially not
      for memory mapped device. We can rule out most error returns since
      the conditions are static and we know they are ok (e.g. offset
      aligned to register stride). Also without proper error handling
      they are not really valuable for the user. Hence remove most of
      them.
      
      The check in the interrupt handler is worth keeping since a
      volatile register won't be readable in case register caching is
      still enabled.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      e291d298
    • Stefan Agner's avatar
      drm/fsl-dcu: specify volatile registers · efb8b491
      Stefan Agner authored
      Since we are using cached registers, we need to specify volatile
      registers explicitly to avoid reading their value from the cache.
      This allows to read the correct interrupt status in fsl_dcu_drm_irq
      and clear the asserted bits only.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      efb8b491