1. 17 Feb, 2016 5 commits
    • Mario Kleiner's avatar
      drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2) · 99b8e715
      Mario Kleiner authored
      This fixes a regression introduced by the new drm_update_vblank_count()
      implementation in Linux 4.4:
      
      Restrict the bump of the software vblank counter in drm_update_vblank_count()
      to a safe maximum value of +1 whenever there is the possibility that
      concurrent readers of vblank timestamps could be active at the moment,
      as the current implementation of the timestamp caching and updating is
      not safe against concurrent readers for calls to store_vblank() with a
      bump of anything but +1. A bump != 1 would very likely return corrupted
      timestamps to userspace, because the same slot in the cache could
      be concurrently written by store_vblank() and read by one of those
      readers in a non-atomic fashion and without the read-retry logic
      detecting this collision.
      
      Concurrent readers can exist while drm_update_vblank_count() is called
      from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank-
      irq callers. However, all those calls are happening with the vbl_lock
      locked thereby preventing a drm_vblank_get(), so the vblank refcount
      can't increase while drm_update_vblank_count() is executing. Therefore
      a zero vblank refcount during execution of that function signals that
      is safe for arbitrary counter bumps if called from outside vblank irq,
      whereas a non-zero count is not safe.
      
      Whenever the function is called from vblank irq, we have to assume concurrent
      readers could show up any time during its execution, even if the refcount
      is currently zero, as vblank irqs are usually only enabled due to the
      presence of readers, and because when it is called from vblank irq it
      can't hold the vbl_lock to protect it from sudden bumps in vblank refcount.
      Therefore also restrict bumps to +1 when the function is called from vblank
      irq.
      
      Such bumps of more than +1 can happen at other times than reenabling
      vblank irqs, e.g., when regular vblank interrupts get delayed by more
      than 1 frame due to long held locks, long irq off periods, realtime
      preemption on RT kernels, or system management interrupts.
      
      A better solution would be to rewrite the timestamp caching to use
      full seqlocks to allow concurrent writes and reads for arbitrary
      vblank counter increments.
      
      v2: Add code comment that this is essentially a hack and should
          be replaced by a full seqlock implementation for caching of
          timestamps.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      
      Cc: <stable@vger.kernel.org> # 4.4+
      Cc: michel@daenzer.net
      Cc: vbabka@suse.cz
      Cc: ville.syrjala@linux.intel.com
      Cc: daniel.vetter@ffwll.ch
      Cc: dri-devel@lists.freedesktop.org
      Cc: alexander.deucher@amd.com
      Cc: christian.koenig@amd.com
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      99b8e715
    • Mario Kleiner's avatar
      drm: No-Op redundant calls to drm_vblank_off() (v2) · e8235891
      Mario Kleiner authored
      Otherwise if a kms driver calls into drm_vblank_off() more than once
      before calling drm_vblank_on() again, the redundant calls to
      vblank_disable_and_save() will call drm_update_vblank_count()
      while hw vblank counters and vblank timestamping are in a undefined
      state during modesets, dpms off etc.
      
      At least with the legacy drm helpers it is not unusual to
      get multiple calls to drm_vblank_off and drm_vblank_on, e.g.,
      half a dozen calls to drm_vblank_off and two calls to drm_vblank_on
      were observed on radeon-kms during dpms-off -> dpms-on transition.
      
      We don't no-op calls from atomic modesetting drivers, as they
      should do a proper job of tracking hw state.
      
      Fixes large jumps of the software maintained vblank counter due to
      the hardware vblank counter resetting to zero during dpms off or
      modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on
      instead of drm_vblank_pre/post_modeset().
      
      This fixes a regression caused by the changes made to
      drm_update_vblank_count() in Linux 4.4.
      
      v2: Don't no-op on atomic modesetting drivers, per suggestion
          of Daniel Vetter.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: <stable@vger.kernel.org> # 4.4+
      Cc: michel@daenzer.net
      Cc: vbabka@suse.cz
      Cc: ville.syrjala@linux.intel.com
      Cc: alexander.deucher@amd.com
      Cc: christian.koenig@amd.com
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      e8235891
    • Gerd Hoffmann's avatar
      drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command · 34855706
      Gerd Hoffmann authored
      This avoids integer overflows on 32bit machines when calculating
      reloc_info size, as reported by Alan Cox.
      
      Cc: stable@vger.kernel.org
      Cc: gnomes@lxorguk.ukuu.org.uk
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      34855706
    • Dave Airlie's avatar
      Merge branch 'exynos-drm-fixes' of... · e8f051e9
      Dave Airlie authored
      Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
      
        Summary:
         - fix compilation warnings on ARM64bit.
         - fix mic driver initialization.
           . MIC is a part of KMS so it converts it to use component framework
             like other KMS drivers did.
         - fix wrong driver state and disable clock order on DECON driver.
         - fix incorrect use of dma_mmap_attrs function.
      
      * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
        drm/exynos/decon: fix disable clocks order
        drm/exynos: fix incorrect cpu address for dma_mmap_attrs()
        drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable
        drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable
        drm/exynos: dsi: restore support for drm bridge
        drm/exynos: mic: make all functions static
        drm/exynos: mic: convert to component framework
        drm/exynos: mic: use devm_clk interface
        drm/exynos: fix types for compilation on 64bit architectures
        drm/exynos: ipp: fix incorrect format specifiers in debug messages
        drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS
      e8f051e9
    • Dave Airlie's avatar
      Revert "drm/dp/mst: change MST detection scheme" · 8ae22cb4
      Dave Airlie authored
      This reverts commit cfcfa086.
      
      This causes the tiling properties to break in some unexpected ways,
      
      Revert it for now.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      8ae22cb4
  2. 16 Feb, 2016 6 commits
  3. 15 Feb, 2016 14 commits
  4. 14 Feb, 2016 15 commits