1. 16 8月, 2015 26 次提交
  2. 15 8月, 2015 4 次提交
  3. 12 8月, 2015 6 次提交
  4. 11 8月, 2015 4 次提交
    • I
      drm/atomic: fix null pointer access to mode_fixup callback · 84524917
      Inki Dae 提交于
      This patch fixes null pointer access incurred when
      encoder driver didn't set its own mode_fixup callback.
      
      mode_fixup callback shoudn't be called if the callback
      of drm_encoder_helper_funcs is NULL.
      
      Changelog v2:
      - change it to else if
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      84524917
    • D
      drm/i915: Use CONFIG_DRM_FBDEV_EMULATION · 0695726e
      Daniel Vetter 提交于
      Instead of our own duplicated one. This fixes a bug in the driver
      unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
      try to unregister the nonexistent fbdev drm_framebuffer.
      
      Cc: Archit Taneja <architt@codeaurora.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0695726e
    • 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
    • D
      drm/atomic: Call ww_acquire_done after check phase is complete · 992cbf19
      Daniel Vetter 提交于
      We want to make sure that no one tries to acquire more locks and
      states, and ww mutexes provide debug facilities for that. So use them.
      
      v2: Only call acquire_done when ->atomic_check was successful to avoid
      falling over an -EDEADLK (spotted by Maarten).
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      992cbf19