1. 08 Nov, 2018 1 commit
  2. 18 Oct, 2018 1 commit
    • Tvrtko Ursulin's avatar
      drm/i915: GEM_WARN_ON considered harmful · bbb8a9d7
      Tvrtko Ursulin authored
      
      
      GEM_WARN_ON currently has dangerous semantics where it is completely
      compiled out on !GEM_DEBUG builds. This can leave users who expect it to
      be more like a WARN_ON, just without a warning in non-debug builds, in
      complete ignorance.
      
      Another gotcha with it is that it cannot be used as a statement. Which is
      again different from a standard kernel WARN_ON.
      
      This patch fixes both problems by making it behave as one would expect.
      
      It can now be used both as an expression and as statement, and also the
      condition evaluates properly in all builds - code under the conditional
      will therefore not unexpectedly disappear.
      
      To satisfy call sites which really want the code under the conditional to
      completely disappear, we add GEM_DEBUG_WARN_ON and convert some of the
      callers to it. This one can also be used as both expression and statement.
      
      >From the above it follows GEM_DEBUG_WARN_ON should be used in situations
      where we are certain the condition will be hit during development, but at
      a place in code where error can be handled to the benefit of not crashing
      the machine.
      
      GEM_WARN_ON on the other hand should be used where condition may happen in
      production and we just want to distinguish the level of debugging output
      emitted between the production and debug build.
      
      v2:
       * Dropped BUG_ON hunk.
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Tomasz Lis <tomasz.lis@intel.com>
      Reviewed-by: default avatarTomasz Lis <tomasz.lis@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181012063142.16080-1-tvrtko.ursulin@linux.intel.com
      bbb8a9d7
  3. 03 Oct, 2018 1 commit
  4. 01 Oct, 2018 3 commits
  5. 27 Sep, 2018 3 commits
  6. 25 Sep, 2018 2 commits
  7. 20 Sep, 2018 1 commit
  8. 14 Sep, 2018 2 commits
  9. 05 Sep, 2018 1 commit
    • Chris Wilson's avatar
      drm/i915: Reduce context HW ID lifetime · 288f1ced
      Chris Wilson authored
      Future gen reduce the number of bits we will have available to
      differentiate between contexts, so reduce the lifetime of the ID
      assignment from that of the context to its current active cycle (i.e.
      only while it is pinned for use by the HW, will it have a constant ID).
      This means that instead of a max of 2k allocated contexts (worst case
      before fun with bit twiddling), we instead have a limit of 2k in flight
      contexts (minus a few that have been pinned by the kernel or by perf).
      
      To reduce the number of contexts id we require, we allocate a context id
      on first and mark it as pinned for as long as the GEM context itself is,
      that is we keep it pinned it while active on each engine. If we exhaust
      our context id space, then we try to reclaim an id from an idle context.
      In the extreme case where all context ids are pinned by active contexts,
      we force the system to idle in order to recover ids.
      
      We cannot reduce the scope of an HW-ID to an engine (allowing the same
      gem_context to have different ids on each engine) as in the future we
      will need to preassign an id before we know which engine the
      context is being executed on.
      
      v2: Improved commentary (Tvrtko) [I tried at least]
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=107788
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180904153117.3907-1-chris@chris-wilson.co.uk
      288f1ced
  10. 04 Sep, 2018 1 commit
    • Tvrtko Ursulin's avatar
      drm/i915/icl: Fix context RPCS programming · b212f0a4
      Tvrtko Ursulin authored
      
      
      There are two issues with the current RPCS programming for Icelake:
      
      Expansion of the slice count bitfield has been missed, as well as the
      required programming workaround for the subslice count bitfield size
      limitation.
      
      1)
      
      Bitfield width for configuring the active slice count has grown so we need
      to program the GEN8_R_PWR_CLK_STATE accordingly.
      
      Current code was always requesting eight times the number of slices (due
      writing to a bitfield starting three bits higher than it should). These
      requests were luckily a) capped by the hardware to the available number of
      slices, and b) we haven't yet exported the code to ask for reduced slice
      configurations.
      
      Due both of the above there was no impact from this incorrect programming
      but we should still fix it.
      
      2)
      
      Due subslice count bitfield being only three bits wide and furthermore
      capped to a maximum documented value of four, special programming
      workaround is needed to enable more than four subslices.
      
      With this programming driver has to consider the GT configuration as
      2x4x8, while the hardware internally translates this to 1x8x8.
      
      A limitation stemming from this is that either a subslice count between
      one and four can be selected, or a subslice count equaling the total
      number of subslices in all selected slices. In other words, odd subslice
      counts greater than four are impossible, as are odd subslice counts
      greater than a single slice subslice count.
      
      This also had no impact in the current code base due breakage from 1)
      always reqesting more than one slice.
      
      While fixing this we also add some asserts to flag up any future bitfield
      overflows.
      
      v2:
       * Use a local in all branches for clarity. (Lionel)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Bspec: 12247
      Reported-by: tony.ye@intel.com
      Suggested-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: tony.ye@intel.com
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180903113007.2643-1-tvrtko.ursulin@linux.intel.com
      b212f0a4
  11. 29 Aug, 2018 1 commit
    • Chris Wilson's avatar
      drm/i915/execlists: Flush tasklet directly from reset-finish · 9e4fa012
      Chris Wilson authored
      
      
      On finishing the reset, the intention is to restart the GPU before we
      relinquish the forcewake taken to handle the reset - the goal being the
      GPU reloads a context before it is allowed to sleep. For this purpose,
      we used tasklet_flush() which although it accomplished the goal of
      restarting the GPU, carried with it a sting in its tail: it cleared the
      TASKLET_STATE_SCHED bit. This meant that if another CPU queued a new
      request to this engine, we would clear the flag and later attempt to
      requeue the tasklet on the local CPU, breaking the per-cpu softirq
      lists.
      
      Remove the dangerous tasklet_kill() and just run the tasklet func
      directly as we know it is safe to do so (the tasklets are internally
      locked to allow mixed usage from direct submission).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180828152702.27536-1-chris@chris-wilson.co.uk
      9e4fa012
  12. 16 Aug, 2018 1 commit
  13. 15 Aug, 2018 1 commit
  14. 10 Aug, 2018 1 commit
  15. 06 Aug, 2018 1 commit
  16. 01 Aug, 2018 1 commit
  17. 27 Jul, 2018 4 commits
  18. 24 Jul, 2018 1 commit
  19. 19 Jul, 2018 2 commits
  20. 16 Jul, 2018 3 commits
  21. 13 Jul, 2018 1 commit
    • Chris Wilson's avatar
      drm/i915/execlists: Drop clear_gtiir() on GPU reset · 60a94324
      Chris Wilson authored
      With the new CSB processing code, we are not vulnerable to delayed
      delivery of a pre-reset interrupt as we use the CSB status pointers in
      the HWSP to decide if we need to parse any CSB events and no longer need
      to wait for the first post-reset interrupt to be assured that the CSB
      mmio registers are valid.
      
      The new icl code to clear registers has a nasty lock inversion:
      [   57.409776] ======================================================
      [   57.409779] WARNING: possible circular locking dependency detected
      [   57.409783] 4.18.0-rc4-CI-CI_DII_1137+ #1 Tainted: G     U  W
      [   57.409785] ------------------------------------------------------
      [   57.409788] swapper/6/0 is trying to acquire lock:
      [   57.409790] 000000004f304ee5 (&engine->timeline.lock/1){-.-.}, at: execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.409841]
                     but task is already holding lock:
      [   57.409844] 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915]
      [   57.409869]
                     which lock already depends on the new lock.
      
      [   57.409872]
                     the existing dependency chain (in reverse order) is:
      [   57.409876]
                     -> #2 (&(&rq->lock)->rlock#2){-.-.}:
      [   57.409900]        notify_ring+0x2b2/0x480 [i915]
      [   57.409922]        gen8_cs_irq_handler+0x39/0xa0 [i915]
      [   57.409943]        gen11_irq_handler+0x2f0/0x420 [i915]
      [   57.409949]        __handle_irq_event_percpu+0x42/0x370
      [   57.409952]        handle_irq_event_percpu+0x2b/0x70
      [   57.409956]        handle_irq_event+0x2f/0x50
      [   57.409959]        handle_edge_irq+0xe7/0x190
      [   57.409964]        handle_irq+0x67/0x160
      [   57.409967]        do_IRQ+0x5e/0x120
      [   57.409971]        ret_from_intr+0x0/0x1d
      [   57.409974]        _raw_spin_unlock_irqrestore+0x4e/0x60
      [   57.409979]        tasklet_action_common.isra.5+0x47/0xb0
      [   57.409982]        __do_softirq+0xd9/0x505
      [   57.409985]        irq_exit+0xa9/0xc0
      [   57.409988]        do_IRQ+0x9a/0x120
      [   57.409991]        ret_from_intr+0x0/0x1d
      [   57.409995]        cpuidle_enter_state+0xac/0x360
      [   57.409999]        do_idle+0x1f3/0x250
      [   57.410004]        cpu_startup_entry+0x6a/0x70
      [   57.410010]        start_secondary+0x19d/0x1f0
      [   57.410015]        secondary_startup_64+0xa5/0xb0
      [   57.410018]
                     -> #1 (&(&dev_priv->irq_lock)->rlock){-.-.}:
      [   57.410081]        clear_gtiir+0x30/0x200 [i915]
      [   57.410116]        execlists_reset+0x6e/0x2b0 [i915]
      [   57.410140]        i915_reset_engine+0x111/0x190 [i915]
      [   57.410165]        i915_handle_error+0x11a/0x4a0 [i915]
      [   57.410198]        i915_hangcheck_elapsed+0x378/0x530 [i915]
      [   57.410204]        process_one_work+0x248/0x6c0
      [   57.410207]        worker_thread+0x37/0x380
      [   57.410211]        kthread+0x119/0x130
      [   57.410215]        ret_from_fork+0x3a/0x50
      [   57.410217]
                     -> #0 (&engine->timeline.lock/1){-.-.}:
      [   57.410224]        _raw_spin_lock_irqsave+0x33/0x50
      [   57.410256]        execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.410289]        submit_notify+0x8d/0x124 [i915]
      [   57.410314]        __i915_sw_fence_complete+0x81/0x250 [i915]
      [   57.410339]        dma_i915_sw_fence_wake+0xd/0x20 [i915]
      [   57.410344]        dma_fence_signal_locked+0x79/0x200
      [   57.410368]        notify_ring+0x2ba/0x480 [i915]
      [   57.410392]        gen8_cs_irq_handler+0x39/0xa0 [i915]
      [   57.410416]        gen11_irq_handler+0x2f0/0x420 [i915]
      [   57.410421]        __handle_irq_event_percpu+0x42/0x370
      [   57.410425]        handle_irq_event_percpu+0x2b/0x70
      [   57.410428]        handle_irq_event+0x2f/0x50
      [   57.410432]        handle_edge_irq+0xe7/0x190
      [   57.410436]        handle_irq+0x67/0x160
      [   57.410439]        do_IRQ+0x5e/0x120
      [   57.410445]        ret_from_intr+0x0/0x1d
      [   57.410449]        cpuidle_enter_state+0xac/0x360
      [   57.410453]        do_idle+0x1f3/0x250
      [   57.410456]        cpu_startup_entry+0x6a/0x70
      [   57.410460]        start_secondary+0x19d/0x1f0
      [   57.410464]        secondary_startup_64+0xa5/0xb0
      [   57.410466]
                     other info that might help us debug this:
      
      [   57.410471] Chain exists of:
                       &engine->timeline.lock/1 --> &(&dev_priv->irq_lock)->rlock --> &(&rq->lock)->rlock#2
      
      [   57.410481]  Possible unsafe locking scenario:
      
      [   57.410485]        CPU0                    CPU1
      [   57.410487]        ----                    ----
      [   57.410490]   lock(&(&rq->lock)->rlock#2);
      [   57.410494]                                lock(&(&dev_priv->irq_lock)->rlock);
      [   57.410498]                                lock(&(&rq->lock)->rlock#2);
      [   57.410503]   lock(&engine->timeline.lock/1);
      [   57.410506]
                      *** DEADLOCK ***
      
      [   57.410511] 4 locks held by swapper/6/0:
      [   57.410514]  #0: 0000000074575789 (&(&dev_priv->irq_lock)->rlock){-.-.}, at: gen11_irq_handler+0x8a/0x420 [i915]
      [   57.410542]  #1: 000000009b29b30e (rcu_read_lock){....}, at: notify_ring+0x1a/0x480 [i915]
      [   57.410573]  #2: 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915]
      [   57.410601]  #3: 000000009b29b30e (rcu_read_lock){....}, at: submit_notify+0x35/0x124 [i915]
      [   57.410635]
                     stack backtrace:
      [   57.410640] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G     U  W         4.18.0-rc4-CI-CI_DII_1137+ #1
      [   57.410644] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.2222.A01.1805300339 05/30/2018
      [   57.410650] Call Trace:
      [   57.410652]  <IRQ>
      [   57.410657]  dump_stack+0x67/0x9b
      [   57.410662]  print_circular_bug.isra.16+0x1c8/0x2b0
      [   57.410666]  __lock_acquire+0x1897/0x1b50
      [   57.410671]  ? lock_acquire+0xa6/0x210
      [   57.410674]  lock_acquire+0xa6/0x210
      [   57.410706]  ? execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.410711]  _raw_spin_lock_irqsave+0x33/0x50
      [   57.410741]  ? execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.410769]  execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.410774]  ? _raw_spin_unlock_irqrestore+0x39/0x60
      [   57.410804]  submit_notify+0x8d/0x124 [i915]
      [   57.410828]  __i915_sw_fence_complete+0x81/0x250 [i915]
      [   57.410854]  dma_i915_sw_fence_wake+0xd/0x20 [i915]
      [   57.410858]  dma_fence_signal_locked+0x79/0x200
      [   57.410882]  notify_ring+0x2ba/0x480 [i915]
      [   57.410907]  gen8_cs_irq_handler+0x39/0xa0 [i915]
      [   57.410933]  gen11_irq_handler+0x2f0/0x420 [i915]
      [   57.410938]  __handle_irq_event_percpu+0x42/0x370
      [   57.410943]  handle_irq_event_percpu+0x2b/0x70
      [   57.410947]  handle_irq_event+0x2f/0x50
      [   57.410951]  handle_edge_irq+0xe7/0x190
      [   57.410955]  handle_irq+0x67/0x160
      [   57.410958]  do_IRQ+0x5e/0x120
      [   57.410962]  common_interrupt+0xf/0xf
      [   57.410965]  </IRQ>
      [   57.410969] RIP: 0010:cpuidle_enter_state+0xac/0x360
      [   57.410972] Code: 44 00 00 31 ff e8 84 93 91 ff 45 84 f6 74 12 9c 58 f6 c4 02 0f 85 31 02 00 00 31 ff e8 7d 30 98 ff e8 e8 0e 94 ff fb 4c 29 fb <48> ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff
      [   57.411015] RSP: 0018:ffffc90000133e90 EFLAGS: 00000216 ORIG_RAX: ffffffffffffffdd
      [   57.411023] RAX: ffff8804ae748040 RBX: 000000000002a97d RCX: 0000000000000000
      [   57.411029] RDX: 0000000000000046 RSI: ffffffff82141263 RDI: ffffffff820f05a7
      [   57.411035] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
      [   57.411041] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8229f078
      [   57.411045] R13: ffff8804ab2adfa8 R14: 0000000000000000 R15: 0000000d5de092e3
      [   57.411052]  do_idle+0x1f3/0x250
      [   57.411055]  cpu_startup_entry+0x6a/0x70
      [   57.411059]  start_secondary+0x19d/0x1f0
      [   57.411064]  secondary_startup_64+0xa5/0xb0
      
      The easiest remedy is to remove the defunct code.
      
      Fixes: ff047a87 ("drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11")
      References: fd8526e5
      
       ("drm/i915/execlists: Trust the CSB")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-3-chris@chris-wilson.co.uk
      60a94324
  22. 11 Jul, 2018 1 commit
  23. 10 Jul, 2018 1 commit
  24. 28 Jun, 2018 5 commits
    • Chris Wilson's avatar
      drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) · 9512f985
      Chris Wilson authored
      Back in commit 27af5eea ("drm/i915: Move execlists irq handler to a
      bottom half"), we came to the conclusion that running our CSB processing
      and ELSP submission from inside the irq handler was a bad idea. A really
      bad idea as we could impose nearly 1s latency on other users of the
      system, on average! Deferring our work to a tasklet allowed us to do the
      processing with irqs enabled, reducing the impact to an average of about
      50us.
      
      We have since eradicated the use of forcewaked mmio from inside the CSB
      processing and ELSP submission, bringing the impact down to around 5us
      (on Kabylake); an order of magnitude better than our measurements 2
      years ago on Broadwell and only about 2x worse on average than the
      gem_syslatency on an unladen system.
      
      In this iteration of the tasklet-vs-direct submission debate, we seek a
      compromise where by we submit new requests immediately to the HW but
      defer processing the CS interrupt onto a tasklet. We gain the advantage
      of low-latency and ksoftirqd avoidance when waking up the HW, while
      avoiding the system-wide starvation of our CS irq-storms.
      
      Comparing the impact on the maximum latency observed (that is the time
      stolen from an RT process) over a 120s interval, repeated several times
      (using gem_syslatency, similar to RT's cyclictest) while the system is
      fully laden with i915 nops, we see that direct submission an actually
      improve the worse case.
      
      Maximum latency in microseconds of a third party RT thread
      (gem_syslatency -t 120 -f 2)
        x Always using tasklets (a couple of >1000us outliers removed)
        + Only using tasklets from CS irq, direct submission of requests
      +------------------------------------------------------------------------+
      |          +                                                             |
      |          +                                                             |
      |          +                                                             |
      |          +       +                                                     |
      |          + +     +                                                     |
      |       +  + +     +  x     x     x                                      |
      |      +++ + +     +  x  x  x  x  x  x                                   |
      |      +++ + ++  + +  *x x  x  x  x  x                                   |
      |      +++ + ++  + *  *x x  *  x  x  x                                   |
      |    + +++ + ++  * * +*xxx  *  x  x  xx                                  |
      |    * +++ + ++++* *x+**xx+ *  x  x xxxx x                               |
      |   **x++++*++**+*x*x****x+ * +x xx xxxx x          x                    |
      |x* ******+***************++*+***xxxxxx* xx*x     xxx +                x+|
      |             |__________MA___________|                                  |
      |      |______M__A________|                                              |
      +------------------------------------------------------------------------+
          N           Min           Max        Median           Avg        Stddev
      x 118            91           186           124     125.28814     16.279137
      + 120            92           187           109     112.00833     13.458617
      Difference at 95.0% confidence
      	-13.2798 +/- 3.79219
      	-10.5994% +/- 3.02677%
      	(Student's t, pooled s = 14.9237)
      
      However the mean latency is adversely affected:
      
      Mean latency in microseconds of a third party RT thread
      (gem_syslatency -t 120 -f 1)
        x Always using tasklets
        + Only using tasklets from CS irq, direct submission of requests
      +------------------------------------------------------------------------+
      |           xxxxxx                                        +   ++         |
      |           xxxxxx                                        +   ++         |
      |           xxxxxx                                      + +++ ++         |
      |           xxxxxxx                                     +++++ ++         |
      |           xxxxxxx                                     +++++ ++         |
      |           xxxxxxx                                     +++++ +++        |
      |           xxxxxxx                                   + ++++++++++       |
      |           xxxxxxxx                                 ++ ++++++++++       |
      |           xxxxxxxx                                 ++ ++++++++++       |
      |          xxxxxxxxxx                                +++++++++++++++     |
      |         xxxxxxxxxxx    x                           +++++++++++++++     |
      |x       xxxxxxxxxxxxx   x           +            + ++++++++++++++++++  +|
      |           |__A__|                                                      |
      |                                                      |____A___|        |
      +------------------------------------------------------------------------+
          N           Min           Max        Median           Avg        Stddev
      x 120         3.506         3.727         3.631     3.6321417    0.02773109
      + 120         3.834         4.149         4.039     4.0375167   0.041221676
      Difference at 95.0% confidence
      	0.405375 +/- 0.00888913
      	11.1608% +/- 0.244735%
      	(Student's t, pooled s = 0.03513)
      
      However, since the mean latency corresponds to the amount of irqsoff
      processing we have to do for a CS interrupt, we only need to speed that
      up to benefit not just system latency but our own throughput.
      
      v2: Remember to defer submissions when under reset.
      v4: Only use direct submission for new requests
      v5: Be aware that with mixing direct tasklet evaluation and deferred
      tasklets, we may end up idling before running the deferred tasklet.
      v6: Remove the redudant likely() from tasklet_is_enabled(), restrict the
      annotation to reset_in_progress().
      v7: Take the full timeline.lock when enabling perf_pmu stats as the
      tasklet is no longer a valid guard. A consequence is that the stats are
      now only valid for engines also using the timeline.lock to process
      state.
      
      Testcase: igt/gem_exec_latency/*rthog*
      References: 27af5eea
      
       ("drm/i915: Move execlists irq handler to a bottom half")
      Suggested-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180628201211.13837-9-chris@chris-wilson.co.uk
      9512f985
    • Chris Wilson's avatar
      drm/i915/execlists: Trust the CSB · fd8526e5
      Chris Wilson authored
      
      
      Now that we use the CSB stored in the CPU friendly HWSP, we do not need
      to track interrupts for when the mmio CSB registers are valid and can
      just check where we read up to last from the cached HWSP. This means we
      can forgo the atomic bit tracking from interrupt, and in the next patch
      it means we can check the CSB at any time.
      
      v2: Change the splitting inside reset_prepare, we only want to lose
      testing the interrupt in this patch, the next patch requires the change
      in locking
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180628201211.13837-8-chris@chris-wilson.co.uk
      fd8526e5
    • Chris Wilson's avatar
      drm/i915/execlists: Stop storing the CSB read pointer in the mmio register · 3800cd19
      Chris Wilson authored
      As we now never read back our current head position from the CSB
      pointers register, and the HW itself doesn't use it to prevent
      overwriting unread CSB entries, we do not need to keep updating the
      register. As it turns out this register is not listed as being shadowed,
      and so requires forcewake -- but we haven't been taking forcewake around
      it so the writes has probably been regularly dropped. Fortuitously, we
      only read the value after a reset where it did not matter, and zero was
      the right answer (well, close enough).
      
      Mika pointed out that this was how we used to do it (accidentally!)
      before he fixed it in commit cc53699b ("drm/i915: Use masked write
      for Context Status Buffer Pointer").
      
      References: cc53699b
      
       ("drm/i915: Use masked write for Context Status Buffer Pointer")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180628201211.13837-7-chris@chris-wilson.co.uk
      3800cd19
    • Chris Wilson's avatar
      drm/i915/execlists: Reset CSB write pointer after reset · f4b58f04
      Chris Wilson authored
      
      
      On HW reset, the HW clears the write pointer (to 0). But since it also
      writes its first CSB entry to slot 0, we need to reset the write pointer
      back to the element before (so the first entry we read is 0).
      
      This is required for the next patch, where we trust the CSB completely!
      
      v2: Use _MASKED_FIELD
      v3: Store the reset value, so that we differentiate between mmio/hwsp
      transparently and without pretense.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180628201211.13837-6-chris@chris-wilson.co.uk
      f4b58f04
    • Chris Wilson's avatar
      drm/i915/execlists: Unify CSB access pointers · bc4237ec
      Chris Wilson authored
      
      
      Following the removal of the last workarounds, the only CSB mmio access
      is for the old vGPU interface. The mmio registers presented by vGPU do
      not require forcewake and can be treated as ordinary volatile memory,
      i.e. they behave just like the HWSP access just at a different location.
      We can reduce the CSB access to a set of read/write/buffer pointers and
      treat the various paths identically and not worry about forcewake.
      (Forcewake is nightmare for worstcase latency, and we want to process
      this all with irqsoff -- no latency allowed!)
      
      v2: Comments, comments, comments. Well, 2 bonus comments.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180628201211.13837-5-chris@chris-wilson.co.uk
      bc4237ec