1. 15 Aug, 2015 13 commits
  2. 14 Aug, 2015 7 commits
  3. 12 Aug, 2015 15 commits
  4. 11 Aug, 2015 5 commits
    • Inki Dae's avatar
      drm/atomic: fix null pointer access to mode_fixup callback · 84524917
      Inki Dae authored
      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: default avatarInki Dae <inki.dae@samsung.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      84524917
    • Daniel Vetter's avatar
      drm/i915: Use CONFIG_DRM_FBDEV_EMULATION · 0695726e
      Daniel Vetter authored
      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: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0695726e
    • Maarten Lankhorst's avatar
      drm/core: Set mode to NULL when connectors in a set drops to 0. · cebbb739
      Maarten Lankhorst authored
      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: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cebbb739
    • Daniel Vetter's avatar
      drm/atomic: Call ww_acquire_done after check phase is complete · 992cbf19
      Daniel Vetter authored
      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: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      992cbf19
    • Daniel Vetter's avatar
      drm/atomic: Paper over locking WARN in default_state_clear · 460e8e2c
      Daniel Vetter authored
      In
      
      commit 6f75cea6
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Nov 19 18:38:07 2014 +0100
      
          drm/atomic: Only destroy connector states with connection mutex held
      
      I tried to fix races of atomic commits against connector
      hot-unplugging. The idea is to ensure lifetimes by holding the
      connection_mutex long enough. That works for synchronous commits, but
      not for async ones.
      
      For async atomic commit we really need to fix up connector lifetimes
      for real. But that's a much bigger task, so just add more duct-tape:
      For cleaning up connector states we currently don't need the connector
      itself. So NULL it out and remove the locking check. Of course that
      check was to protect the entire sequence, but the modeset itself
      should be save since currently DP MST hot-removal does a dpms-off. And
      that should synchronize with any outstanding async atomic commit.
      
      Or at least that's my hope, this is all a giant mess.
      Reported-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      460e8e2c