1. 09 Apr, 2018 4 commits
  2. 07 Apr, 2018 1 commit
    • Lyude Paul's avatar
      drm/i915/dp: Send DPCD ON for MST before phy_up · be1c63c8
      Lyude Paul authored
      When doing a modeset where the sink is transitioning from D3 to D0 , it
      would sometimes be possible for the initial power_up_phy() to start
      timing out. This would only be observed in the last action before the
      sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
      originally thought this might be an issue with us accidentally shutting
      off the aux block when putting the sink into D3, but since the DP spec
      mandates that sinks must wake up within 1ms while we have 100ms to
      respond to an ESI irq, this didn't really add up. Turns out that the
      problem is more subtle then that:
      
      It turns out that the timeout is from us not enabling DPMS on the MST
      hub before actually trying to initiate sideband communications. This
      would cause the first sideband communication (power_up_phy()), to start
      timing out because the sink wasn't ready to respond. Afterwards, we
      would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
      intel_ddi_pre_enable_dp(), which would actually result in waking up the
      sink so that sideband requests would work again.
      
      Since DPMS is what lets us actually bring the hub up into a state where
      sideband communications become functional again, we just need to make
      sure to enable DPMS on the display before attempting to perform sideband
      communications.
      
      Changes since v1:
      - Remove comment above if (!intel_dp->is_mst) - vsryjala
      - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
        keep enable/disable paths symmetrical
      - Improve commit message - dhnkrn
      Changes since v2:
      - Only send DPMS off when we're disabling the last sink, and only send
        DPMS on when we're enabling the first sink - dhnkrn
      Changes since v3:
      - Check against is_mst, not intel_dp->is_mst - dhnkrn/vsyrjala
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: ad260ab3 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
      Link: https://patchwork.freedesktop.org/patch/msgid/20180407011053.22437-1-lyude@redhat.com
      be1c63c8
  3. 06 Apr, 2018 15 commits
  4. 05 Apr, 2018 1 commit
    • Chris Wilson's avatar
      drm/i915: Only call finish_reset after a prepare_reset · 40da1d31
      Chris Wilson authored
      If we skip the intel_prepare_reset(), we should also skip the
      intel_display_reset(). If we we use a flag set by intel_prepare_reset()
      then we do not have to second guess based on external user controlled
      state whether or not the prepare was called before deciding to finish
      it after the reset. igt/gem_eio is one such example that may tweak
      i915.reset faster than the code is expecting, leading to
      
      [  190.233528] =====================================
      [  190.233534] WARNING: bad unlock balance detected!
      [  190.233540] 4.16.0-rc7-g335ef9849310-drmtip_10+ #1 Tainted: G     U
      [  190.233547] -------------------------------------
      [  190.233553] gem_eio/1348 is trying to release lock (crtc_ww_class_acquire) at:
      [  190.233569] [<ffffffff895c7810>] drm_modeset_acquire_fini+0x0/0x60
      [  190.233575] but there are no more locks to release!
      [  190.233580]
                     other info that might help us debug this:
      [  190.233588] 3 locks held by gem_eio/1348:
      [  190.233592]  #0:  (&f->f_pos_lock){+.+.}, at: [<00000000ab90c784>] __fdget_pos+0x3a/0x50
      [  190.233607]  #1:  (sb_writers#11){.+.+}, at: [<00000000e1529265>] vfs_write+0x188/0x1a0
      [  190.233622]  #2:  (&attr->mutex){+.+.}, at: [<0000000011f40afe>] simple_attr_write+0x36/0xd0
      [  190.233635]
                     stack backtrace:
      [  190.233644] CPU: 0 PID: 1348 Comm: gem_eio Tainted: G     U           4.16.0-rc7-g335ef9849310-drmtip_10+ #1
      [  190.233655] Hardware name: Dell Inc.                 OptiPlex GX280               /0G8310, BIOS A04 02/09/2005
      [  190.233664] Call Trace:
      [  190.233674]  dump_stack+0x67/0x95
      [  190.233682]  ? drm_modeset_backoff+0x1b0/0x1b0
      [  190.233690]  print_unlock_imbalance_bug+0xd2/0xe0
      [  190.233698]  ? drm_modeset_backoff+0x1b0/0x1b0
      [  190.233704]  lock_release+0x23e/0x300
      [  190.233712]  drm_modeset_acquire_fini+0x16/0x60
      [  190.233835]  intel_finish_reset+0x72/0x160 [i915]
      [  190.233894]  i915_reset_device+0x1e9/0x240 [i915]
      [  190.233953]  ? __intel_get_crtc_scanline+0x1c0/0x1c0 [i915]
      [  190.233962]  ? work_on_cpu_safe+0x50/0x50
      [  190.234020]  i915_handle_error+0x1f2/0x470 [i915]
      [  190.234031]  ? __might_fault+0x39/0x90
      [  190.234037]  ? __might_fault+0x39/0x90
      [  190.234099]  i915_wedged_set+0x7f/0xc0 [i915]
      [  190.234107]  simple_attr_write+0xb0/0xd0
      [  190.234117]  full_proxy_write+0x51/0x80
      [  190.234125]  __vfs_write+0x21/0x140
      [  190.234133]  ? rcu_read_lock_sched_held+0x6f/0x80
      [  190.234140]  ? rcu_sync_lockdep_assert+0x29/0x50
      [  190.234147]  ? __sb_start_write+0x152/0x1f0
      [  190.234152]  ? __sb_start_write+0x168/0x1f0
      [  190.234159]  vfs_write+0xbd/0x1a0
      [  190.234166]  SyS_write+0x40/0xa0
      [  190.234173]  ? do_syscall_64+0x19/0x1b0
      [  190.234180]  do_syscall_64+0x6b/0x1b0
      [  190.234188]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
      [  190.234196] RIP: 0033:0x7f84c1b392b7
      [  190.234201] RSP: 002b:00007f84b6755b00 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
      [  190.234211] RAX: ffffffffffffffda RBX: 0000000000000046 RCX: 00007f84c1b392b7
      [  190.234218] RDX: 0000000000000002 RSI: 000055ec20abc8d6 RDI: 0000000000000046
      [  190.234225] RBP: 000055ec20abc8d6 R08: 0000000000000000 R09: 0000000000000000
      [  190.234231] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002
      [  190.234238] R13: 0000000000000000 R14: 00007f84b0000b20 R15: 000055ec20ce4eb8
      
      Testcase: igt/gem_eio
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180405123714.3638-1-chris@chris-wilson.co.uk
      40da1d31
  5. 04 Apr, 2018 6 commits
  6. 03 Apr, 2018 1 commit
  7. 30 Mar, 2018 12 commits