1. 17 2月, 2016 12 次提交
    • M
      drm/radeon/pm: Handle failure of drm_vblank_get. · e0b34e38
      Mario Kleiner 提交于
      Make sure that drm_vblank_get/put() stay balanced in
      case drm_vblank_get fails, by skipping the corresponding
      put.
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: michel@daenzer.net
      Cc: dri-devel@lists.freedesktop.org
      Cc: alexander.deucher@amd.com
      Cc: christian.koenig@amd.com
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e0b34e38
    • M
      drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2) · bb74fc1b
      Mario Kleiner 提交于
      drm_vblank_offdelay can have three different types of values:
      
      < 0 is to be always treated the same as dev->vblank_disable_immediate
      = 0 is to be treated as "never disable vblanks"
      > 0 is to be treated as disable immediate if kms driver wants it
          that way via dev->vblank_disable_immediate. Otherwise it is
          a disable timeout in msecs.
      
      This got broken in Linux 3.18+ for the implementation of
      drm_vblank_on. If the user specified a value of zero which should
      always reenable vblank irqs in this function, a kms driver could
      override the users choice by setting vblank_disable_immediate
      to true. This patch fixes the regression and keeps the user in
      control.
      
      v2: Only reenable vblank if there are clients left or the user
          requested to "never disable vblanks" via offdelay 0. Enabling
          vblanks even in the "delayed disable" case (offdelay > 0) was
          specifically added by Ville in commit cd19e52a
          ("drm: Kick start vblank interrupts at drm_vblank_on()"),
          but after discussion it turns out that this was done by accident.
      
          Citing Ville: "I think it just ended up as a mess due to changing
          some of the semantics of offdelay<0 vs. offdelay==0 vs.
          disable_immediate during the review of the series. So yeah, given
          how drm_vblank_put() works now, I'd just make this check for
          offdelay==0."
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      
      Cc: <stable@vger.kernel.org> # 3.18+
      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: NDave Airlie <airlied@redhat.com>
      bb74fc1b
    • M
      drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4 · c61934ed
      Mario Kleiner 提交于
      Changes to drm_update_vblank_count() in Linux 4.4 broke the
      behaviour of the pre/post modeset functions as the new update
      code doesn't deal with hw vblank counter resets inbetween calls
      to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it
      should.
      
      This causes mistreatment of such hw counter resets as counter
      wraparound, and thereby large forward jumps of the software
      vblank counter which in turn cause vblank event dispatching
      and vblank waits to fail/hang --> userspace clients hang.
      
      This symptom was reported on radeon-kms to cause a infinite
      hang of KDE Plasma 5 shell's login procedure, preventing users
      from logging in.
      
      Fix this by detecting when drm_update_vblank_count() is called
      inside a pre->post modeset interval. If so, clamp valid vblank
      increments to the safe values 0 and 1, pretty much restoring
      the update behavior of the old update code of Linux 4.3 and
      earlier. Also reset the last recorded hw vblank count at call
      to drm_vblank_post_modeset() to be safe against hw that after
      modesetting, dpms on etc. only fires its first vblank irq after
      drm_vblank_post_modeset() was already called.
      Reported-by: NVlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: NVlastimil Babka <vbabka@suse.cz>
      
      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: NDave Airlie <airlied@redhat.com>
      c61934ed
    • M
      drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2) · 99b8e715
      Mario Kleiner 提交于
      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: NMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: NDaniel 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: NDave Airlie <airlied@redhat.com>
      99b8e715
    • M
      drm: No-Op redundant calls to drm_vblank_off() (v2) · e8235891
      Mario Kleiner 提交于
      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: NMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: NDaniel 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: NDave Airlie <airlied@redhat.com>
      e8235891
    • G
      drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command · 34855706
      Gerd Hoffmann 提交于
      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: NGerd Hoffmann <kraxel@redhat.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      34855706
    • D
      Merge branch 'exynos-drm-fixes' of... · e8f051e9
      Dave Airlie 提交于
      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
    • D
      Revert "drm/dp/mst: change MST detection scheme" · 8ae22cb4
      Dave Airlie 提交于
      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: NDave Airlie <airlied@redhat.com>
      8ae22cb4
    • L
      Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 · 65c23c65
      Linus Torvalds 提交于
      Pull cifs fixes from Steve French:
       "A small set of cifs fixes.
      
        I am still reviewing some more, recently submitted SMB3 fixes, but
        these three are small and safe and ready now"
      
      * 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
        cifs: fix erroneous return value
        cifs: fix potential overflow in cifs_compose_mount_options
        cifs: remove redundant check for null string pointer
      65c23c65
    • L
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · d82834ee
      Linus Torvalds 提交于
      Pull ARM KVM fixes from Paolo Bonzini:
       - Fix for an unpleasant crash when the VM is created without a timer
       - Allow HYP mode to access the full PA space, and not only 40bit
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        arm64: KVM: Configure TCR_EL2.PS at runtime
        KVM: arm/arm64: Fix reference to uninitialised VGIC
      d82834ee
    • P
      Merge tag 'kvm-arm-for-4.5-rc4' of... · c53d7a84
      Paolo Bonzini 提交于
      Merge tag 'kvm-arm-for-4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
      
      KVM/ARM fixes for 4.5-rc4
      
      - Fix for an unpleasant crash when the VM is created without a timer
      - Allow HYP mode to access the full PA space, and not only 40bit
      c53d7a84
    • L
      Merge tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu · 87bbcfde
      Linus Torvalds 提交于
      Pull IOMMU SVM fixes from David Woodhouse:
       "Minor register size and interrupt acknowledgement fixes which only
        showed up in testing on newer hardware, but mostly a fix to the MM
        refcount handling to prevent a recursive refcount issue when mmap() is
        used on the file descriptor associated with a bound PASID"
      
      * tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu:
        iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts
        iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG
        iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users
      87bbcfde
  2. 16 2月, 2016 2 次提交
  3. 15 2月, 2016 26 次提交