1. 03 Mar, 2017 34 commits
  2. 02 Mar, 2017 6 commits
    • Chris Wilson's avatar
      drm/i915: Drop spinlocks around adding to the client request list · c8659efa
      Chris Wilson authored
      Adding to the tail of the client request list as the only other user is
      in the throttle ioctl that iterates forwards over the list. It only
      needs protection against deletion of a request as it reads it, it simply
      won't see a new request added to the end of the list, or it would be too
      early and rejected. We can further reduce the number of spinlocks
      required when throttling by removing stale requests from the client_list
      as we throttle.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170302122525.19675-1-chris@chris-wilson.co.uk
      c8659efa
    • Ville Syrjälä's avatar
      drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks · 5be6e334
      Ville Syrjälä authored
      Currently ILK-BDW explicitly disable LP1+ watermarks from their
      .init_clock_gating() hooks. Unfortunately that hook gets called way too
      late since by that time we've already initialized all the watermark
      state tracking which then gets out of sync with the hardware state.
      
      We may eventually want to consider killing off the explicit LP1+
      disable from .init_clock_gating(). In the meantime however, we can
      avoid the problem by reordering the init sequence such that
      intel_modeset_init_hw()->intel_init_clock_gating() gets called
      prior to the hardware state takeover.
      
      I suppose prior to the two stage watermark programming we were
      magically saved by something that forced the watermarks to be
      reprogrammed fully after .init_clock_gating() got called. But
      now that no longer happens.
      
      Note that the diff might look a bit odd as it kills off one
      call of intel_update_cdclk(), but that's fine because
      intel_modeset_init_hw() does the exact same thing. Previously
      we just did it twice.
      
      Actually even this new init sequence is pretty bogus as
      .init_clock_gating() really should be called before any gem
      hardware init since it can  configure various clock gating
      workarounds and whatnot that affect the GT side as well. Also
      intel_modeset_init() really should get split up into better
      defined init stages. Another "fun" detail is that
      intel_modeset_gem_init() is where RPS/RC6 gets configured.
      Why that is done from the display code is beyond me. I've
      decided to leave all this be for now, and just try to fix
      the init sequence enough for watermarks to work.
      
      Cc: stable@vger.kernel.org
      Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com>
      Cc: David Purton <dcpurton@marshwiggle.net>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reported-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Reported-by: default avatarDavid Purton <dcpurton@marshwiggle.net>
      Tested-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96645
      Fixes: ed4a6a7c ("drm/i915: Add two-stage ILK-style watermark programming (v11)")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170220140443.30891-1-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5be6e334
    • Chris Wilson's avatar
      drm/i915: Include power-management state in gpu error dump · e5aac87e
      Chris Wilson authored
      Useful for double checking that the device is powered up when it hung,
      include both the status of the power management and our rpm wakelock.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170302151544.16915-1-chris@chris-wilson.co.ukReviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      e5aac87e
    • Chris Wilson's avatar
      drm/i915: Include GT/seqno activity in engine/hangcheck debugfs · f73b5674
      Chris Wilson authored
      Whilst investigating some mysterious failures with hangcheck not running
      during gem_busy/basic-hang-default, the question is why did we decide to
      cancel the retire_work (which queues the hangcheck)? That decision is
      based around GT activity, so include that information in the debug
      report.
      
      v2: Include the GT awake status in the error state
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170302150356.9713-1-chris@chris-wilson.co.ukReviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      f73b5674
    • Chris Wilson's avatar
      drm/i915/guc: Disable irq for __i915_guc_submit wq_lock · 25afdf89
      Chris Wilson authored
      __i915_guc_submit may be, despite my assertion, called from outside of
      an irq-safe spinlock so we need to use a full spin_lock_irqsave and not
      cheat using a spin_lock. (The initial notify callback from the completed
      fence is called before the spinlock is taken to wake up all waiters and
      call their callbacks.)
      
      [   48.166581] kernel BUG at drivers/gpu/drm/i915/i915_guc_submission.c:527!
      [   48.166617] invalid opcode: 0000 [#1] PREEMPT SMP
      [   48.166644] Modules linked in: i915 prime_numbers x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mei_me mei i2c_i801 netconsole i2c_hid [last unloaded: i915]
      [   48.166733] CPU: 2 PID: 5 Comm: kworker/u8:0 Tainted: G     U          4.10.0nightly-170302-guc_scrub+ #19
      [   48.166778] Hardware name:                  /NUC6i5SYB, BIOS SYSKLi35.86A.0054.2016.0930.1102 09/30/2016
      [   48.166835] Workqueue: i915 __intel_autoenable_gt_powersave [i915]
      [   48.166865] task: ffff88084ab7cf40 task.stack: ffffc90000064000
      [   48.166921] RIP: 0010:__i915_guc_submit+0x1e6/0x2a0 [i915]
      [   48.166953] RSP: 0018:ffffc90000067c80 EFLAGS: 00010202
      [   48.166979] RAX: 0000000000000202 RBX: ffff8808465e0c68 RCX: 0000000000000201
      [   48.167016] RDX: 0000000080000201 RSI: ffff88084ab7d798 RDI: ffff88082b8a8040
      [   48.167054] RBP: ffffc90000067cd8 R08: 0000000000000001 R09: 0000000000000000
      [   48.167085] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88082b8a8148
      [   48.167126] R13: 0000000000000000 R14: ffff88082f440000 R15: ffff88082e85e660
      [   48.167156] FS:  0000000000000000(0000) GS:ffff88086ed00000(0000) knlGS:0000000000000000
      [   48.167195] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   48.167226] CR2: 000055862ffcdc2c CR3: 0000000001e0f000 CR4: 00000000003406e0
      [   48.167257] Call Trace:
      [   48.168112]  ? trace_hardirqs_on+0xd/0x10
      [   48.168966]  ? _raw_spin_unlock_irqrestore+0x4a/0x80
      [   48.169831]  i915_guc_submit+0x1a/0x20 [i915]
      [   48.170680]  submit_notify+0x89/0xc0 [i915]
      [   48.171512]  __i915_sw_fence_complete+0x175/0x220 [i915]
      [   48.172340]  i915_sw_fence_complete+0x2a/0x50 [i915]
      [   48.173158]  i915_sw_fence_commit+0x21/0x30 [i915]
      [   48.173968]  __i915_add_request+0x238/0x530 [i915]
      [   48.174764]  __intel_autoenable_gt_powersave+0x8b/0xb0 [i915]
      [   48.175549]  process_one_work+0x218/0x690
      [   48.176318]  ? process_one_work+0x197/0x690
      [   48.177183]  worker_thread+0x4e/0x4a0
      [   48.178039]  kthread+0x10c/0x140
      [   48.178878]  ? process_one_work+0x690/0x690
      [   48.179718]  ? kthread_create_on_node+0x40/0x40
      [   48.180568]  ret_from_fork+0x31/0x40
      [   48.181423] Code: 02 00 00 43 89 84 ae 50 11 00 00 e8 75 01 62 e1 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 c1 e0 20 48 09 c2 49 89 d0 eb 82 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 49 c1 e8 20 44 89 43 34 4a
      [   48.183336] RIP: __i915_guc_submit+0x1e6/0x2a0 [i915] RSP: ffffc90000067c80
      Reported-by: default avatarArkadiusz Hiler <arkadiusz.hiler@intel.com>
      Fixes: 349ab919 ("drm/i915/guc: Make wq_lock irq-safe")
      Fixes: 67b807a8 ("drm/i915: Delay disabling the user interrupt for breadcrumbs")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170302145323.12886-1-chris@chris-wilson.co.ukReviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarArkadiusz Hiler <arkadiusz.hiler@intel.com>
      Tested-by: default avatarArkadiusz Hiler <arkadiusz.hiler@intel.com>
      25afdf89
    • Chris Wilson's avatar
      drm/i915: s/assert_spin_locked/lockdep_assert_held/ · 67520415
      Chris Wilson authored
      assert_spin_locked() becomes an unconditionally compiled BUG_ON(),
      adding debug code right into the heart of critical routines like
      interrupt handlers.
      
         text	   data	    bss	    dec	    hex
      1296480	  19944	   2272	1318696	 141f28	before (lockdep disabled)
      1295984	  19944	   2272	1318200	 141d38	after
      
      1336261	  21139	   3208	1360608	 14c2e0	before (lockdep enabled)
      1339920	  21139	   3208	1364267	 14d12b	after
      
      Small saving for release; hopefully more instructive in debug.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170302132801.599-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      67520415