1. 24 Oct, 2019 2 commits
    • Chris Wilson's avatar
      drm/i915/selftests: Flush any i915_active callback work as well · 7f47211e
      Chris Wilson authored
      Make trebly sure that all possible callbacks and their delayed brethren
      are complete before asserting that the i915_active should be idle after
      flushing all barriers.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191023235359.27132-1-chris@chris-wilson.co.uk
      7f47211e
    • Chris Wilson's avatar
      drm/i915/selftests: Flush interrupts before disabling tasklets · 93100fde
      Chris Wilson authored
      When setting up the system to perform the atomic reset, we need to
      serialise with any ongoing interrupt tasklet or else:
      
      <0> [472.951428] i915_sel-4442    0d..1 466527056us : __i915_request_submit: rcs0 fence 11659:2, current 0
      <0> [472.951554] i915_sel-4442    0d..1 466527059us : __execlists_submission_tasklet: rcs0: queue_priority_hint:-2147483648, submit:yes
      <0> [472.951681] i915_sel-4442    0d..1 466527061us : trace_ports: rcs0: submit { 11659:2, 0:0 }
      <0> [472.951805] i915_sel-4442    0.... 466527114us : __igt_atomic_reset_engine: i915_reset_engine(rcs0:active) under hardirq
      <0> [472.951932] i915_sel-4442    0d... 466527115us : intel_engine_reset: rcs0 flags=11d
      <0> [472.952056] i915_sel-4442    0d... 466527117us : execlists_reset_prepare: rcs0: depth<-1
      <0> [472.952179] i915_sel-4442    0d... 466527119us : intel_engine_stop_cs: rcs0
      <0> [472.952305]   <idle>-0       1..s1 466527119us : process_csb: rcs0 cs-irq head=3, tail=4
      <0> [472.952431] i915_sel-4442    0d... 466527122us : __intel_gt_reset: engine_mask=1
      <0> [472.952557]   <idle>-0       1..s1 466527124us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000
      <0> [472.952683]   <idle>-0       1..s1 466527130us : trace_ports: rcs0: promote { 11659:2*, 0:0 }
      <0> [472.952808] i915_sel-4442    0d... 466527131us : execlists_reset: rcs0
      <0> [472.952933] i915_sel-4442    0d..1 466527133us : process_csb: rcs0 cs-irq head=3, tail=4
      <0> [472.953059] i915_sel-4442    0d..1 466527134us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000
      <0> [472.953185] i915_sel-4442    0d..1 466527136us : trace_ports: rcs0: preempted { 11659:2*, 0:0 }
      <0> [472.953310] i915_sel-4442    0d..1 466527150us : assert_pending_valid: Nothing pending for promotion!
      <0> [472.953436] i915_sel-4442    0d..1 466527158us : process_csb: process_csb:1930 GEM_BUG_ON(!assert_pending_valid(execlists, "promote"))
      
      We have the same CSB events being seen by process_csb() on two different
      processors. One being issued by the reset in the test, the other by the
      interrupt; this scenario is supposed to be prevented by flushing the
      interrupt tasklet with tasklet_disable() before we enter the atomic
      reset.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112069Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191023232443.17450-1-chris@chris-wilson.co.uk
      93100fde
  2. 23 Oct, 2019 12 commits
  3. 22 Oct, 2019 20 commits
  4. 21 Oct, 2019 6 commits