1. 25 1月, 2017 4 次提交
    • C
      drm/i915: Move atomic state free from out of fence release · eb955eee
      Chris Wilson 提交于
      Fences are required to support being released from under an atomic context.
      The drm_atomic_state struct may take a mutex when being released and so
      we cannot drop a reference to the drm_atomic_state from the fence release
      path directly, and so we need to defer that unreference to a worker.
      
      [  326.576697] WARNING: CPU: 2 PID: 366 at kernel/sched/core.c:7737 __might_sleep+0x5d/0x80
      [  326.576816] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffffc0359549>] intel_breadcrumbs_signaler+0x59/0x270 [i915]
      [  326.576818] Modules linked in: rfcomm fuse snd_hda_codec_hdmi bnep snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer input_leds led_class snd punit_atom_debug btusb btrtl btbcm btintel intel_rapl bluetooth i915 drm_kms_helper syscopyarea sysfillrect iwlwifi sysimgblt soundcore fb_sys_fops mei_txe cfg80211 drm pwm_lpss_platform pwm_lpss pinctrl_cherryview fjes acpi_pad parport_pc ppdev parport autofs4
      [  326.576899] CPU: 2 PID: 366 Comm: i915/signal:0 Tainted: G     U          4.10.0-rc3-patser+ #5030
      [  326.576902] Hardware name:                  /NUC5PPYB, BIOS PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
      [  326.576905] Call Trace:
      [  326.576920]  dump_stack+0x4d/0x6d
      [  326.576926]  __warn+0xc0/0xe0
      [  326.576931]  warn_slowpath_fmt+0x5a/0x80
      [  326.577004]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
      [  326.577075]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
      [  326.577079]  __might_sleep+0x5d/0x80
      [  326.577087]  mutex_lock+0x1b/0x40
      [  326.577133]  drm_property_free_blob+0x1e/0x80 [drm]
      [  326.577167]  ? drm_property_destroy+0xe0/0xe0 [drm]
      [  326.577200]  drm_mode_object_unreference+0x5c/0x70 [drm]
      [  326.577233]  drm_property_unreference_blob+0xe/0x10 [drm]
      [  326.577260]  __drm_atomic_helper_crtc_destroy_state+0x14/0x40 [drm_kms_helper]
      [  326.577278]  drm_atomic_helper_crtc_destroy_state+0x10/0x20 [drm_kms_helper]
      [  326.577352]  intel_crtc_destroy_state+0x9/0x10 [i915]
      [  326.577388]  drm_atomic_state_default_clear+0xea/0x1d0 [drm]
      [  326.577462]  intel_atomic_state_clear+0xd/0x20 [i915]
      [  326.577497]  drm_atomic_state_clear+0x1a/0x30 [drm]
      [  326.577532]  __drm_atomic_state_free+0x13/0x60 [drm]
      [  326.577607]  intel_atomic_commit_ready+0x6f/0x78 [i915]
      [  326.577670]  i915_sw_fence_release+0x3a/0x50 [i915]
      [  326.577733]  dma_i915_sw_fence_wake+0x39/0x80 [i915]
      [  326.577741]  dma_fence_signal+0xda/0x120
      [  326.577812]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
      [  326.577884]  intel_breadcrumbs_signaler+0xb1/0x270 [i915]
      [  326.577889]  kthread+0x127/0x130
      [  326.577961]  ? intel_engine_remove_wait+0x1a0/0x1a0 [i915]
      [  326.577964]  ? kthread_stop+0x120/0x120
      [  326.577970]  ret_from_fork+0x22/0x30
      
      Fixes: c004a90b ("drm/i915: Restore nonblocking awaits for modesetting")
      Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170123212939.30345-1-chris@chris-wilson.co.uk
      Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      eb955eee
    • C
      drm/i915: Emit dma-fence (and execlists submit) first from signaler · 7c9e934e
      Chris Wilson 提交于
      When introduced, I thought that reducing client latency from the
      signaler was the priority. Since its inception the signaler has become
      responsible for keeping the execlists full, via the dma-fence. As this
      is very important to minimise overall execution time, signal the
      dma-fence first and then signal any waiting clients.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170124110009.28947-8-chris@chris-wilson.co.uk
      7c9e934e
    • C
      drm/i915: Dequeue execlists on a new request if any port is available · 48ea2554
      Chris Wilson 提交于
      If the second ELSP port is available, schedule the execlists tasklet to
      see if the new request can occupy it.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170124110009.28947-7-chris@chris-wilson.co.uk
      48ea2554
    • C
      drm/i915: Only attempt to pass the first request to execlists · 3833281a
      Chris Wilson 提交于
      Only the first request added to the execlist queue can be submitted. If
      this request is not the first request on the queue, it means that there
      are already higher priority requests waiting upon the tasklet and
      kicking it will make no difference.
      
      This is more relevant for a later patch, where we more eagerly try and
      kick the tasklet to handle the submission of new requests.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170124110009.28947-6-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      3833281a
  2. 24 1月, 2017 8 次提交
  3. 23 1月, 2017 18 次提交
  4. 21 1月, 2017 9 次提交
  5. 20 1月, 2017 1 次提交