1. 17 Apr, 2018 1 commit
  2. 14 Apr, 2018 2 commits
  3. 13 Apr, 2018 3 commits
  4. 12 Apr, 2018 2 commits
    • Jani Nikula's avatar
    • Jani Nikula's avatar
      drm/i915/bios: filter out invalid DDC pins from VBT child devices · f212bf9a
      Jani Nikula authored
      The VBT contains the DDC pin to use for specific ports. Alas, sometimes
      the field appears to contain bogus data, and while we check for it later
      on in intel_gmbus_get_adapter() we fail to check the returned NULL on
      errors. Oops results.
      
      The simplest approach seems to be to catch and ignore the bogus DDC pins
      already at the VBT parsing phase, reverting to fixed per port default
      pins. This doesn't guarantee display working, but at least it prevents
      the oops. And we continue to be fuzzed by VBT.
      
      One affected machine is Dell Latitude 5590 where a BIOS upgrade added
      invalid DDC pins.
      
      Typical backtrace:
      
      [   35.461411] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin))
      [   35.461432] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461437] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
      [   35.461445] CPU: 6 PID: 411 Comm: kworker/u16:2 Not tainted 4.16.0-rc7.x64-g1cda370ffded #1
      [   35.461447] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
      [   35.461450] Workqueue: events_unbound async_run_entry_fn
      [   35.461465] RIP: 0010:intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461467] RSP: 0018:ffff9b4e43d47c40 EFLAGS: 00010286
      [   35.461469] RAX: 0000000000000000 RBX: ffff98f90639f800 RCX: ffffffffae051960
      [   35.461471] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000246
      [   35.461472] RBP: ffff98f905410000 R08: 0000004d062a83f6 R09: 00000000000003bd
      [   35.461474] R10: 0000000000000031 R11: ffffffffad4eda58 R12: ffff98f905410000
      [   35.461475] R13: ffff98f9064c1000 R14: ffff9b4e43d47cf0 R15: ffff98f905410000
      [   35.461477] FS:  0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000
      [   35.461479] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   35.461481] CR2: 00007f5682359008 CR3: 00000001b700c005 CR4: 00000000003606e0
      [   35.461483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   35.461484] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   35.461486] Call Trace:
      [   35.461501]  intel_hdmi_set_edid+0x37/0x27f [i915]
      [   35.461515]  intel_hdmi_detect+0x7c/0x97 [i915]
      [   35.461518]  drm_helper_probe_single_connector_modes+0xe1/0x6c0
      [   35.461521]  drm_setup_crtcs+0x129/0xa6a
      [   35.461523]  ? __switch_to_asm+0x34/0x70
      [   35.461525]  ? __switch_to_asm+0x34/0x70
      [   35.461527]  ? __switch_to_asm+0x40/0x70
      [   35.461528]  ? __switch_to_asm+0x34/0x70
      [   35.461529]  ? __switch_to_asm+0x40/0x70
      [   35.461531]  ? __switch_to_asm+0x34/0x70
      [   35.461532]  ? __switch_to_asm+0x40/0x70
      [   35.461534]  ? __switch_to_asm+0x34/0x70
      [   35.461536]  __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
      [   35.461538]  ? __switch_to_asm+0x40/0x70
      [   35.461541]  ? _cond_resched+0x10/0x33
      [   35.461557]  intel_fbdev_initial_config+0xf/0x1c [i915]
      [   35.461560]  async_run_entry_fn+0x2e/0xf5
      [   35.461563]  process_one_work+0x15b/0x364
      [   35.461565]  worker_thread+0x2c/0x3a0
      [   35.461567]  ? process_one_work+0x364/0x364
      [   35.461568]  kthread+0x10c/0x122
      [   35.461570]  ? _kthread_create_on_node+0x5d/0x5d
      [   35.461572]  ret_from_fork+0x35/0x40
      [   35.461574] Code: 74 16 89 f6 48 8d 04 b6 48 c1 e0 05 48 29 f0 48 8d 84 c7 e8 11 00 00 c3 48 c7 c6 b0 19 1e c0 48 c7 c7 64 8a 1c c0 e8 47 88 ed ec <0f> 0b 31 c0 c3 8b 87 a4 04 00 00 80 e4 fc 09 c6 89 b7 a4 04 00
      [   35.461604] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461606] ---[ end trace 4fe1e63e2dd93373 ]---
      [   35.461609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [   35.461613] IP: i2c_transfer+0x4/0x86
      [   35.461614] PGD 0 P4D 0
      [   35.461616] Oops: 0000 [#1] SMP PTI
      [   35.461618] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
      [   35.461624] CPU: 6 PID: 411 Comm: kworker/u16:2 Tainted: G        W        4.16.0-rc7.x64-g1cda370ffded #1
      [   35.461625] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
      [   35.461628] Workqueue: events_unbound async_run_entry_fn
      [   35.461630] RIP: 0010:i2c_transfer+0x4/0x86
      [   35.461631] RSP: 0018:ffff9b4e43d47b30 EFLAGS: 00010246
      [   35.461633] RAX: ffff9b4e43d47b6e RBX: 0000000000000005 RCX: 0000000000000001
      [   35.461635] RDX: 0000000000000002 RSI: ffff9b4e43d47b80 RDI: 0000000000000000
      [   35.461636] RBP: ffff9b4e43d47bd8 R08: 0000004d062a83f6 R09: 00000000000003bd
      [   35.461638] R10: 0000000000000031 R11: ffffffffad4eda58 R12: 0000000000000002
      [   35.461639] R13: 0000000000000001 R14: ffff9b4e43d47b6f R15: ffff9b4e43d47c07
      [   35.461641] FS:  0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000
      [   35.461643] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   35.461645] CR2: 0000000000000010 CR3: 00000001b700c005 CR4: 00000000003606e0
      [   35.461646] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   35.461647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   35.461649] Call Trace:
      [   35.461652]  drm_do_probe_ddc_edid+0xb3/0x128
      [   35.461654]  drm_get_edid+0xe5/0x38d
      [   35.461669]  intel_hdmi_set_edid+0x45/0x27f [i915]
      [   35.461684]  intel_hdmi_detect+0x7c/0x97 [i915]
      [   35.461687]  drm_helper_probe_single_connector_modes+0xe1/0x6c0
      [   35.461689]  drm_setup_crtcs+0x129/0xa6a
      [   35.461691]  ? __switch_to_asm+0x34/0x70
      [   35.461693]  ? __switch_to_asm+0x34/0x70
      [   35.461694]  ? __switch_to_asm+0x40/0x70
      [   35.461696]  ? __switch_to_asm+0x34/0x70
      [   35.461697]  ? __switch_to_asm+0x40/0x70
      [   35.461698]  ? __switch_to_asm+0x34/0x70
      [   35.461700]  ? __switch_to_asm+0x40/0x70
      [   35.461701]  ? __switch_to_asm+0x34/0x70
      [   35.461703]  __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
      [   35.461705]  ? __switch_to_asm+0x40/0x70
      [   35.461707]  ? _cond_resched+0x10/0x33
      [   35.461724]  intel_fbdev_initial_config+0xf/0x1c [i915]
      [   35.461727]  async_run_entry_fn+0x2e/0xf5
      [   35.461729]  process_one_work+0x15b/0x364
      [   35.461731]  worker_thread+0x2c/0x3a0
      [   35.461733]  ? process_one_work+0x364/0x364
      [   35.461734]  kthread+0x10c/0x122
      [   35.461736]  ? _kthread_create_on_node+0x5d/0x5d
      [   35.461738]  ret_from_fork+0x35/0x40
      [   35.461739] Code: 5c fa e1 ad 48 89 df e8 ea fb ff ff e9 2a ff ff ff 0f 1f 44 00 00 31 c0 e9 43 fd ff ff 31 c0 45 31 e4 e9 c5 fd ff ff 41 54 55 53 <48> 8b 47 10 48 83 78 10 00 74 70 41 89 d4 48 89 f5 48 89 fb 65
      [   35.461756] RIP: i2c_transfer+0x4/0x86 RSP: ffff9b4e43d47b30
      [   35.461757] CR2: 0000000000000010
      [   35.461759] ---[ end trace 4fe1e63e2dd93374 ]---
      
      Based on a patch by Fei Li.
      
      v2: s/reverting/sticking/ (Chris)
      
      Cc: stable@vger.kernel.org
      Cc: Fei Li <fei.li@intel.com>
      Co-developed-by: default avatarFei Li <fei.li@intel.com>
      Reported-by: default avatarPavel Nakonechnyi <zorg1331@gmail.com>
      Reported-and-tested-by: default avatarSeweryn Kokot <sewkokot@gmail.com>
      Reported-and-tested-by: default avatarLaszlo Valko <valko@linux.karinthy.hu>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105549
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105961Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180411131519.9091-1-jani.nikula@intel.com
      f212bf9a
  5. 11 Apr, 2018 5 commits
  6. 10 Apr, 2018 5 commits
  7. 09 Apr, 2018 19 commits
  8. 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
  9. 06 Apr, 2018 2 commits
    • Chris Wilson's avatar
      drm/i915: Pass the set of guilty engines to i915_reset() · d0667e9c
      Chris Wilson authored
      Currently, we rely on inspecting the hangcheck state from within the
      i915_reset() routines to determine which engines were guilty of the
      hang. This is problematic for cases where we want to run
      i915_handle_error() and call i915_reset() independently of hangcheck.
      Instead of relying on the indirect parameter passing, turn it into an
      explicit parameter providing the set of stalled engines which then are
      treated as guilty until proven innocent.
      
      While we are removing the implicit stalled parameter, also make the
      reason into an explicit parameter to i915_reset(). We still need a
      back-channel for i915_handle_error() to hand over the task to the locked
      waiter, but let's keep that its own channel rather than incriminate
      another.
      
      This leaves stalled/seqno as being private to hangcheck, with no more
      nefarious snooping by reset, be it whole-device or per-engine. \o/
      
      The only real issue now is that this makes it crystal clear that we
      don't actually do any testing of hangcheck per se in
      drv_selftest/live_hangcheck, merely of resets!
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Jeff McGee <jeff.mcgee@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-2-chris@chris-wilson.co.uk
      d0667e9c
    • Chris Wilson's avatar
      drm/i915: Treat i915_reset_engine() as guilty until proven innocent · bba0869b
      Chris Wilson authored
      If we are resetting just one engine, we know it has stalled. So we can
      pass the stalled parameter directly to i915_gem_reset_engine(), which
      alleviates the necessity to poke at the generic engine->hangcheck.stalled
      magic variable, leaving that under control of hangcheck as its name
      implies. Other than simplifying by removing the indirect parameter along
      this path, this allows us to introduce new reset mechanisms that run
      independently of hangcheck.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Jeff McGee <jeff.mcgee@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-1-chris@chris-wilson.co.uk
      bba0869b