1. 30 Mar, 2016 7 commits
    • Chris Wilson's avatar
      drm/i915: Rename __force_wake_get to __force_wake_auto · b208ba8e
      Chris Wilson authored
      __force_wake_get() only acquires a temporary wakeref on forcewake that is
      automatically released when a timer expires. When reading the code
      again, I confused __intel_uncore_forcewake_get() for __force_wake_get()
      and to my shame thought I found a bug in unbalanced wake_count handling.
      
      I claim that if the function had been called __force_wake_auto() instead
      I would not have embarrassed myself.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1458829907-26596-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      b208ba8e
    • Joonas Lahtinen's avatar
      drm/i915: Rename GGTT init functions · d85489d3
      Joonas Lahtinen authored
      Rename and document the GGTT init functions to give a better
      idea of the context where they are called from.
      
      i915_gem_gtt_init => i915_ggtt_init_hw
      i915_gem_init_global_gtt => i915_gem_init_ggtt
      i915_global_gtt_cleanup => i915_ggtt_cleanup_hw
      
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1458830866-12578-1-git-send-email-joonas.lahtinen@linux.intel.com
      d85489d3
    • Matthew Auld's avatar
      drm/i915: BUG_ON when ggtt_view is NULL · ade7daa1
      Matthew Auld authored
      Lets BUG_ON and don't bother with a WARN and returning an error, so we can
      remove the need to pollute the code with error handling, after all it is
      a programmer error to provide NULL view. Also while we're here remove
      redundant NULL ggtt_view check.
      
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Signed-off-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1458834860-7898-1-git-send-email-matthew.auld@intel.com
      ade7daa1
    • Bjørn Mork's avatar
      drm/i915: fix deadlock on lid open · 9f54d4bd
      Bjørn Mork authored
      commit e2c8b870 moved modeset locking inside resume/suspend
      functions, but missed a code path only executed on lid close/open
      on older hardware. The result was a deadlock when closing and
      opening the lid without suspending on such hardware:
      
       =============================================
       [ INFO: possible recursive locking detected ]
       4.6.0-rc1 #385 Not tainted
       ---------------------------------------------
       kworker/0:3/88 is trying to acquire lock:
        (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
      
       but task is already holding lock:
        (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(&dev->mode_config.mutex);
         lock(&dev->mode_config.mutex);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       7 locks held by kworker/0:3/88:
        #0:  ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
        #1:  ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
        #2:  ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65
        #3:  (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915]
        #4:  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
        #5:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm]
        #6:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm]
      
       stack backtrace:
       CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385
       Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
       Workqueue: kacpi_notify acpi_os_execute_deferred
        0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0
        ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70
        000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0
       Call Trace:
        [<ffffffff8124af06>] dump_stack+0x67/0x90
        [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71
        [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a
        [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb
        [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb
        [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
        [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4
        [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
        [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
        [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
        [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
        [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
        [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
        [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
        [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm]
        [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm]
        [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915]
        [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c
        [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65
        [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16
        [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button]
        [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button]
        [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b
        [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64
        [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20
        [<ffffffff81068f17>] process_one_work+0x265/0x50b
        [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd
        [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
        [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
        [<ffffffff8106e2d6>] kthread+0xe0/0xe8
        [<ffffffff8107bc47>] ? local_clock+0x19/0x22
        [<ffffffff81484f42>] ret_from_fork+0x22/0x40
        [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5
      
      Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.")
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no
      9f54d4bd
    • Daniel Vetter's avatar
      68d4aee9
    • Lyude's avatar
      drm/i915: Call intel_dp_mst_resume() before resuming displays · a16b7658
      Lyude authored
      Since we need MST devices ready before we try to resume displays,
      calling this after intel_display_resume() can result in some issues with
      various laptop docks where the monitor won't turn back on after
      suspending the system.
      
      This order was originally changed in
      
      	commit e7d6f7d7 ("drm/i915: resume MST after reading back hw state")
      
      In order to fix some unclaimed register errors, however the actual cause
      of those has since been fixed.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      [danvet: Resolve conflicts with locking changes.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a16b7658
    • Lukas Wunner's avatar
      drm/i915: Fix races on fbdev · a7442b93
      Lukas Wunner authored
      The ->lastclose callback invokes intel_fbdev_restore_mode() and has
      been witnessed to run before intel_fbdev_initial_config_async()
      has finished.
      
      We might likewise receive hotplug events before we've had a chance to
      fully set up the fbdev.
      
      Fix by waiting for the asynchronous thread to finish.
      
      v2:
      An async_synchronize_full() was also added to intel_fbdev_set_suspend()
      in v1 which turned out to be entirely gratuitous. It caused a deadlock
      on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela
      for CI support) and was unnecessary since a device is never suspended
      until its ->probe callback (and all asynchronous tasks it scheduled)
      have finished. See dpm_prepare(), which calls wait_for_device_probe(),
      which calls async_synchronize_full().
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580Reported-by: default avatarGustav Fägerlind <gustav.fagerlind@gmail.com>
      Reported-by: default avatar"Li, Weinan Z" <weinan.z.li@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20160309115147.67B2B6E0D3@gabe.freedesktop.org
      a7442b93
  2. 29 Mar, 2016 4 commits
  3. 24 Mar, 2016 4 commits
  4. 23 Mar, 2016 18 commits
  5. 22 Mar, 2016 5 commits
  6. 21 Mar, 2016 2 commits