1. 22 10月, 2016 2 次提交
  2. 17 10月, 2016 2 次提交
  3. 19 9月, 2016 1 次提交
  4. 24 8月, 2016 1 次提交
  5. 23 8月, 2016 1 次提交
  6. 18 8月, 2016 1 次提交
  7. 16 8月, 2016 1 次提交
  8. 12 8月, 2016 1 次提交
  9. 09 8月, 2016 1 次提交
  10. 22 6月, 2016 2 次提交
  11. 09 6月, 2016 1 次提交
  12. 07 6月, 2016 2 次提交
  13. 31 5月, 2016 1 次提交
  14. 17 5月, 2016 1 次提交
    • L
      drm/fb_helper: Fix references to dev->mode_config.num_connector · 255f0e7c
      Lyude 提交于
      During boot, MST hotplugs are generally expected (even if no physical
      hotplugging occurs) and result in DRM's connector topology changing.
      This means that using num_connector from the current mode configuration
      can lead to the number of connectors changing under us. This can lead to
      some nasty scenarios in fbcon:
      
      - We allocate an array to the size of dev->mode_config.num_connectors.
      - MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
      - We try to loop through each element in the array using the new value
        of dev->mode_config.num_connectors, and end up going out of bounds
        since dev->mode_config.num_connectors is now larger then the array we
        allocated.
      
      fb_helper->connector_count however, will always remain consistent while
      we do a modeset in fb_helper.
      
      Note: This is just polish for 4.7, Dave Airlie's drm_connector
      refcounting fixed these bugs for real. But it's good enough duct-tape
      for stable kernel backporting, since backporting the refcounting
      changes is way too invasive.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NLyude <cpaul@redhat.com>
      [danvet: Clarify why we need this. Also remove the now unused "dev"
      local variable to appease gcc.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com
      255f0e7c
  15. 12 5月, 2016 1 次提交
  16. 05 5月, 2016 2 次提交
  17. 02 5月, 2016 1 次提交
  18. 15 2月, 2016 2 次提交
  19. 12 2月, 2016 1 次提交
  20. 25 1月, 2016 1 次提交
  21. 21 12月, 2015 1 次提交
    • M
      drm/fb-helper: Use proper plane mask for fb cleanup · 7118fd9b
      Matt Roper 提交于
      pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the
      legacy FB fields (plane->fb and plane->old_fb).  However it was building
      the plane mask to pass to this function incorrectly (the bitwise OR was
      using plane indices rather than plane masks).  The end result was that
      sometimes the legacy pointers would become out of sync with the atomic
      pointers.  If another operation tried to re-set the same FB onto the
      plane, we might end up with the pointers back in sync, but improper
      reference counts, which would eventually lead to system crashes when we
      accessed a pointer to a prematurely-destroyed FB.
      
      The cause here was a very subtle bug introduced in commit:
      
              commit 07d3bad6
              Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
              Date:   Wed Nov 11 11:29:11 2015 +0100
      
                  drm/core: Fix old_fb handling in pan_display_atomic.
      
      I found the crashes were most easily reproduced (on i915 at least) by
      starting X and then VT switching to a VT that wasn't running a console
      instance...the sequence of vt/fbcon entries that happen in that case
      trigger a reference count mismatch and crash the system.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7118fd9b
  22. 17 11月, 2015 2 次提交
  23. 19 10月, 2015 2 次提交
  24. 02 10月, 2015 1 次提交
  25. 25 9月, 2015 1 次提交
    • M
      drm/fbdev: Update legacy plane->fb refcounting for atomic restore · 94284037
      Matt Roper 提交于
      Starting with commit
      
              commit 28cc504e
              Author: Rob Clark <robdclark@gmail.com>
              Date:   Tue Aug 25 15:36:00 2015 -0400
      
                  drm/i915: enable atomic fb-helper
      
      I've been seeing some panics on i915 when the DRM master shuts down that appear
      to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
      dropping our initial FB's reference count to 0 and freeing it, which causes a
      crash when we try to restore it later).  Digging deeper, the state FB
      refcounting is working as expected, but we seem to be missing proper
      refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
      
      Tracking plane->old_fb and then doing a ref/unref at the end of the
      fbdev restore like we do in the legacy ioctl's ensures we don't miscount
      references on plane->fb and avoids the panics.
      
      v2 from Daniel:
      
      Really do what the atomic ioctl does:
      - Also update plane->fb and plane->crtc.
      - Clear out plane->old_fb on failures too.
      
      v3: git add everything. Oops.
      
      v4: Also clear old_fb in all other failure paths, spotted by David.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (v1)
      Reviewd-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      94284037
  26. 17 9月, 2015 2 次提交
  27. 08 9月, 2015 2 次提交
  28. 11 8月, 2015 1 次提交
    • M
      drm/core: Set mode to NULL when connectors in a set drops to 0. · cebbb739
      Maarten Lankhorst 提交于
      Without this when a MST connector is removed drm_atomic_helper_set_config
      can complain about set->mode && !set->num_connectors.
      
      ------------[ cut here ]------------
      WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_helper.c:1673 drm_atomic_helper_set_config+0x22e/0x420()
      CPU: 2 PID: 2403 Comm: kms_flip Not tainted 4.2.0-rc5 #4233
      Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
       ffffffff81ac75e8 ffff88004e4ffbf8 ffffffff81714c34 0000000080000000
       0000000000000000 ffff88004e4ffc38 ffffffff8107bf81 ffff88004e4ffc48
       ffff8800d8ca0690 ffff8800d8d7a080 ffff8800d8cc2290 ffff8800d07bc9f0
      Call Trace:
       [<ffffffff81714c34>] dump_stack+0x4f/0x7b
       [<ffffffff8107bf81>] warn_slowpath_common+0x81/0xc0
       [<ffffffff8107c065>] warn_slowpath_null+0x15/0x20
       [<ffffffff813d9e3e>] drm_atomic_helper_set_config+0x22e/0x420
       [<ffffffff813da174>] ? drm_atomic_helper_plane_set_property+0x84/0xc0
       [<ffffffff813ee101>] drm_mode_set_config_internal+0x61/0x100
       [<ffffffff813dc4ed>] restore_fbdev_mode+0xbd/0xe0
       [<ffffffff813de1e4>] drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70
       [<ffffffffc0123d11>] intel_fbdev_restore_mode+0x21/0x80 [i915]
       [<ffffffffc014bf69>] i915_driver_lastclose+0x9/0x10 [i915]
       [<ffffffff813e2429>] drm_lastclose+0x29/0x130
       [<ffffffff813e2844>] drm_release+0x314/0x500
       [<ffffffff81194795>] __fput+0xe5/0x1f0
       [<ffffffff811948d9>] ____fput+0x9/0x10
       [<ffffffff810968d8>] task_work_run+0x88/0xb0
       [<ffffffff8107d53f>] do_exit+0x37f/0xa90
       [<ffffffff8127e258>] ? selinux_file_ioctl+0x48/0xc0
       [<ffffffff81277dfe>] ? security_file_ioctl+0x3e/0x60
       [<ffffffff8107ec80>] do_group_exit+0x40/0xa0
       [<ffffffff8107ecef>] SyS_exit_group+0xf/0x10
       [<ffffffff8171bdd7>] entry_SYSCALL_64_fastpath+0x12/0x6a
      ---[ end trace 0daf358c49351567 ]---
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cebbb739
  29. 06 8月, 2015 2 次提交