1. 04 Dec, 2018 6 commits
    • Tvrtko Ursulin's avatar
      drm/i915: Verify GT workaround state after GPU init · 094304be
      Tvrtko Ursulin authored
      Since we now have all the GT workarounds in a table, by adding a simple
      shared helper function we can now verify that their values are still
      applied after some interesting events in the lifetime of the driver.
      
      Initially we only do this after GPU initialization.
      
      v2:
       Chris Wilson:
       * Simplify verification by realizing it's a simple xor and and.
       * Remove verification from engine reset path.
       * Return bool straight away from the verify API.
      
      v3:
       * API rename. (Chris Wilson)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-4-tvrtko.ursulin@linux.intel.com
      094304be
    • Tvrtko Ursulin's avatar
      drm/i915: Introduce per-engine workarounds · 4a15c75c
      Tvrtko Ursulin authored
      We stopped re-applying the GT workarounds after engine reset since commit
      59b449d5 ("drm/i915: Split out functions for different kinds of
      workarounds").
      
      Issue with this is that some of the GT workarounds live in the MMIO space
      which gets lost during engine resets. So far the registers in 0x2xxx and
      0xbxxx address range have been identified to be affected.
      
      This losing of applied workarounds has obvious negative effects and can
      even lead to hard system hangs (see the linked Bugzilla).
      
      Rather than just restoring this re-application, because we have also
      observed that it is not safe to just re-write all GT workarounds after
      engine resets (GPU might be live and weird hardware states can happen),
      we introduce a new class of per-engine workarounds and move only the
      affected GT workarounds over.
      
      Using the framework introduced in the previous patch, we therefore after
      engine reset, re-apply only the workarounds living in the affected MMIO
      address ranges.
      
      v2:
       * Move Wa_1406609255:icl to engine workarounds as well.
       * Rename API. (Chris Wilson)
       * Drop redundant IS_KABYLAKE. (Chris Wilson)
       * Re-order engine wa/ init so latest platforms are first. (Rodrigo Vivi)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=107945
      Fixes: 59b449d5 ("drm/i915: Split out functions for different kinds of workarounds")
      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>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Acked-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181203133341.10258-1-tvrtko.ursulin@linux.intel.com
      4a15c75c
    • Tvrtko Ursulin's avatar
      drm/i915: Record GT workarounds in a list · 25d140fa
      Tvrtko Ursulin authored
      To enable later verification of GT workaround state at various stages of
      driver lifetime, we record the list of applicable ones per platforms to a
      list, from which they are also applied.
      
      The added data structure is a simple array of register, mask and value
      items, which is allocated on demand as workarounds are added to the list.
      
      This is a temporary implementation which later in the series gets fused
      with the existing per context workaround list handling. It is separated at
      this stage since the following patch fixes a bug which needs to be as easy
      to backport as possible.
      
      Also, since in the following patch we will be adding a new class of
      workarounds (per engine) which can be applied from interrupt context, we
      straight away make the provision for safe read-modify-write cycle.
      
      v2:
       * Change dev_priv to i915 along the init path. (Chris Wilson)
       * API rename. (Chris Wilson)
      
      v3:
       * Remove explicit list size tracking in favour of growing the allocation
         in power of two chunks. (Chris Wilson)
      
      v4:
       Chris Wilson:
       * Change wa_list_finish to early return.
       * Copy workarounds using the compiler for static checking.
       * Do not bother zeroing unused entries.
       * Re-order struct i915_wa_list.
      
      v5:
       * kmalloc_array.
       * Whitespace cleanup.
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181203133319.10174-1-tvrtko.ursulin@linux.intel.com
      25d140fa
    • Jonathan Gray's avatar
      drm/i915: change i915_sw_fence license to MIT · 635b3bc6
      Jonathan Gray authored
      Change the license of the i915_sw_fence files to MIT matching
      most of the other i915 files.  This makes it possible to use them
      in a new port of i915 to OpenBSD.
      
      Besides some mechanical tree wide changes Chris Wilson is the sole
      author of these files with Intel holding the copyright.
      
      Intel's legal team have given permission to change the license according
      to Joonas Lahtinen.
      
      v2: expand commit message and note permission from Intel legal
      Signed-off-by: default avatarJonathan Gray <jsg@jsg.id.au>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181129013051.17525-1-jsg@jsg.id.au
      635b3bc6
    • Chris Wilson's avatar
      drm/i915: Complete the fences as they are cancelled due to wedging · 3800960a
      Chris Wilson authored
      We inspect the requests under the assumption that they will be marked as
      completed when they are removed from the queue. Currently however, in the
      process of wedging the requests will be removed from the queue before they
      are completed, so rearrange the code to complete the fences before the
      locks are dropped.
      
      <1>[  354.473346] BUG: unable to handle kernel NULL pointer dereference at 0000000000000250
      <6>[  354.473363] PGD 0 P4D 0
      <4>[  354.473370] Oops: 0000 [#1] PREEMPT SMP PTI
      <4>[  354.473380] CPU: 0 PID: 4470 Comm: gem_eio Tainted: G     U            4.20.0-rc4-CI-CI_DRM_5216+ #1
      <4>[  354.473393] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018
      <4>[  354.473480] RIP: 0010:__i915_schedule+0x311/0x5e0 [i915]
      <4>[  354.473490] Code: 49 89 44 24 20 4d 89 4c 24 28 4d 89 29 44 39 b3 a0 04 00 00 7d 3a 41 8b 44 24 78 85 c0 74 13 48 8b 93 78 04 00 00 48 83 e2 fc <39> 82 50 02 00 00 79 1e 44 89 b3 a0 04 00 00 48 8d bb d0 03 00 00
      <4>[  354.473515] RSP: 0018:ffffc900001bba90 EFLAGS: 00010046
      <4>[  354.473524] RAX: 0000000000000003 RBX: ffff8882624c8008 RCX: f34a737800000000
      <4>[  354.473535] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8882624c8048
      <4>[  354.473545] RBP: ffffc900001bbab0 R08: 000000005963f1f1 R09: 0000000000000000
      <4>[  354.473556] R10: ffffc900001bba10 R11: ffff8882624c8060 R12: ffff88824fdd7b98
      <4>[  354.473567] R13: ffff88824fdd7bb8 R14: 0000000000000001 R15: ffff88824fdd7750
      <4>[  354.473578] FS:  00007f44b4b5b980(0000) GS:ffff888277e00000(0000) knlGS:0000000000000000
      <4>[  354.473590] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4>[  354.473599] CR2: 0000000000000250 CR3: 000000026976e000 CR4: 0000000000340ef0
      <4>[  354.473611] Call Trace:
      <4>[  354.473622]  ? lock_acquire+0xa6/0x1c0
      <4>[  354.473677]  ? i915_schedule_bump_priority+0x57/0xd0 [i915]
      <4>[  354.473736]  i915_schedule_bump_priority+0x72/0xd0 [i915]
      <4>[  354.473792]  i915_request_wait+0x4db/0x840 [i915]
      <4>[  354.473804]  ? get_pwq.isra.4+0x2c/0x50
      <4>[  354.473813]  ? ___preempt_schedule+0x16/0x18
      <4>[  354.473824]  ? wake_up_q+0x70/0x70
      <4>[  354.473831]  ? wake_up_q+0x70/0x70
      <4>[  354.473882]  ? gen6_rps_boost+0x118/0x120 [i915]
      <4>[  354.473936]  i915_gem_object_wait_fence+0x8a/0x110 [i915]
      <4>[  354.473991]  i915_gem_object_wait+0x113/0x500 [i915]
      <4>[  354.474047]  i915_gem_wait_ioctl+0x11c/0x2f0 [i915]
      <4>[  354.474101]  ? i915_gem_unset_wedged+0x210/0x210 [i915]
      <4>[  354.474113]  drm_ioctl_kernel+0x81/0xf0
      <4>[  354.474123]  drm_ioctl+0x2de/0x390
      <4>[  354.474175]  ? i915_gem_unset_wedged+0x210/0x210 [i915]
      <4>[  354.474187]  ? finish_task_switch+0x95/0x260
      <4>[  354.474197]  ? lock_acquire+0xa6/0x1c0
      <4>[  354.474207]  do_vfs_ioctl+0xa0/0x6e0
      <4>[  354.474217]  ? __fget+0xfc/0x1e0
      <4>[  354.474225]  ksys_ioctl+0x35/0x60
      <4>[  354.474233]  __x64_sys_ioctl+0x11/0x20
      <4>[  354.474241]  do_syscall_64+0x55/0x190
      <4>[  354.474251]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[  354.474260] RIP: 0033:0x7f44b3de65d7
      <4>[  354.474267] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
      <4>[  354.474293] RSP: 002b:00007fff974948e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      <4>[  354.474305] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f44b3de65d7
      <4>[  354.474316] RDX: 00007fff97494940 RSI: 00000000c010646c RDI: 0000000000000007
      <4>[  354.474327] RBP: 00007fff97494940 R08: 0000000000000000 R09: 00007f44b40bbc40
      <4>[  354.474337] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c010646c
      <4>[  354.474348] R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
      
      v2: Avoid floating requests.
      v3: Can't call dma_fence_signal() under the timeline lock!
      v4: Can't call dma_fence_signal() from inside another fence either.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181203113701.12106-2-chris@chris-wilson.co.uk
      3800960a
    • Chris Wilson's avatar
      drm/i915/dp: Fix inconsistent indenting · 0ce611c9
      Chris Wilson authored
      Always show the FEC capability as it is initialised to 0 before error.
      Fixing,
      
      drivers/gpu/drm/i915/intel_dp.c:3846 intel_dp_get_dsc_sink_cap() warn: inconsistent indenting
      
      Fixes: 08cadae8 ("i915/dp/fec: Cache the FEC_CAPABLE DPCD register")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Manasi Navare <manasi.d.navare@intel.com>
      Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
      Reviewed-by: default avatarAnusha Srivatsa <anusha.srivatsa@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181120202439.13017-2-chris@chris-wilson.co.uk
      0ce611c9
  2. 03 Dec, 2018 29 commits
  3. 30 Nov, 2018 5 commits