1. 08 8月, 2017 1 次提交
  2. 12 6月, 2017 1 次提交
  3. 30 5月, 2017 3 次提交
  4. 27 2月, 2017 1 次提交
  5. 13 12月, 2016 1 次提交
  6. 25 11月, 2016 1 次提交
  7. 17 11月, 2016 1 次提交
  8. 01 11月, 2016 2 次提交
  9. 14 10月, 2016 3 次提交
  10. 22 9月, 2016 1 次提交
  11. 23 8月, 2016 3 次提交
  12. 17 8月, 2016 1 次提交
  13. 10 8月, 2016 4 次提交
  14. 04 7月, 2016 1 次提交
  15. 03 7月, 2016 1 次提交
  16. 30 6月, 2016 2 次提交
  17. 24 6月, 2016 3 次提交
  18. 22 6月, 2016 1 次提交
    • I
      drm/i915/ibx, cpt: Don't attempt to register eDP if LVDS was detected · 97a824e1
      Imre Deak 提交于
      Atm on IBX/CPT we attempt to detect if eDP is present even if LVDS was
      already detected and an encoder for it was registered. This involves
      trying to read out the eDP DPCD, which in turn needs the same power
      sequencer that LVDS uses. Poking at the VDD line at an unexpected time
      may or may not interfere with the LVDS panel, but it's probably safer to
      prevent this. Registering both an LVDS and an eDP connector would also
      present a similar problem accessing the shared PPS at any point later in
      an unexpected way.
      
      We also need this to be able fix PPS initialization before its first use
      in the next patch. For that we want to be sure that PPS is not in use
      by LVDS.
      
      v2:
      - Split out the PPS init fix to a separate patch. (Chris)
      - Add comment about eDP init depending on LVDS init. (Chris)
      - Make the use of the intel_encoder ptr less error prone.
      v3:
      - Use IBX/CPT reference instead of the incorrect ILK, add a WARN about
        this. (Ville)
      v4:
      - Use a helper to get the lvds encoder instead of opencoding the same.
        (Ville)
      
      CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
      Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v3)
      Link: http://patchwork.freedesktop.org/patch/msgid/1466499109-20240-2-git-send-email-imre.deak@intel.com
      97a824e1
  19. 19 6月, 2016 1 次提交
  20. 11 6月, 2016 1 次提交
  21. 10 6月, 2016 1 次提交
  22. 02 6月, 2016 1 次提交
  23. 30 5月, 2016 1 次提交
  24. 11 5月, 2016 1 次提交
  25. 04 5月, 2016 1 次提交
  26. 02 5月, 2016 1 次提交
  27. 07 4月, 2016 1 次提交
    • B
      drm/i915: fix deadlock on lid open · 42bf7b46
      Bjørn Mork 提交于
      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: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no
      (cherry picked from commit 9f54d4bd)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      42bf7b46