1. 25 1月, 2017 1 次提交
    • 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
  2. 23 1月, 2017 3 次提交
  3. 19 1月, 2017 4 次提交
  4. 18 1月, 2017 3 次提交
  5. 15 1月, 2017 2 次提交
  6. 12 1月, 2017 1 次提交
  7. 11 1月, 2017 1 次提交
    • T
      drm/i915: Use new CRC debugfs API · 8c6b709d
      Tomeu Vizoso 提交于
      The core provides now an ABI to userspace for generation of frame CRCs,
      so implement the ->set_crc_source() callback and reuse as much code as
      possible with the previous ABI implementation.
      
      When handling the pageflip interrupt, we skip 1 or 2 frames depending on
      the HW because they contain wrong values. For the legacy ABI for
      generating frame CRCs, this was done in userspace but now that we have a
      generic ABI it's better if it's not exposed by the kernel.
      
      v2:
          - Leave the legacy implementation in place as the ABI implementation
            in the core is incompatible with it.
      v3:
          - Use the "cooked" vblank counter so we have a whole 32 bits.
          - Make sure we don't mess with the state of the legacy CRC capture
            ABI implementation.
      v4:
          - Keep use of get_vblank_counter as in the legacy code, will be
            changed in a followup commit.
      
      v5:
          - Skip first frame or two as it's known that they contain wrong
            data.
          - A few fixes suggested by Emil Velikov.
      
      v6:
          - Rework programming of the HW registers to preserve previous
            behavior.
      
      v7:
          - Address whitespace issue.
          - Added a comment on why in the implementation of the new ABI we
            skip the 1st or 2nd frames.
      
      v9:
          - Add stub for intel_crtc_set_crc_source.
      
      v12:
          - Rebased.
          - Remove stub for intel_crtc_set_crc_source and instead set the
            callback to NULL (Jani Nikula).
      
      v15:
          - Rebased.
      Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
      Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
      Reviewed-by: NRobert Foss <robert.foss@collabora.com>
      
      irq
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170110134305.26326-2-tomeu.vizoso@collabora.com
      8c6b709d
  8. 04 1月, 2017 1 次提交
  9. 03 1月, 2017 1 次提交
  10. 02 1月, 2017 1 次提交
  11. 30 12月, 2016 4 次提交
  12. 22 12月, 2016 1 次提交
  13. 20 12月, 2016 3 次提交
  14. 19 12月, 2016 1 次提交
    • C
      drm/i915: Unify active context tracking between legacy/execlists/guc · e8a9c58f
      Chris Wilson 提交于
      The requests conversion introduced a nasty bug where we could generate a
      new request in the middle of constructing a request if we needed to idle
      the system in order to evict space for a context. The request to idle
      would be executed (and waited upon) before the current one, creating a
      minor havoc in the seqno accounting, as we will consider the current
      request to already be completed (prior to deferred seqno assignment) but
      ring->last_retired_head would have been updated and still could allow
      us to overwrite the current request before execution.
      
      We also employed two different mechanisms to track the active context
      until it was switched out. The legacy method allowed for waiting upon an
      active context (it could forcibly evict any vma, including context's),
      but the execlists method took a step backwards by pinning the vma for
      the entire active lifespan of the context (the only way to evict was to
      idle the entire GPU, not individual contexts). However, to circumvent
      the tricky issue of locking (i.e. we cannot take struct_mutex at the
      time of i915_gem_request_submit(), where we would want to move the
      previous context onto the active tracker and unpin it), we take the
      execlists approach and keep the contexts pinned until retirement.
      The benefit of the execlists approach, more important for execlists than
      legacy, was the reduction in work in pinning the context for each
      request - as the context was kept pinned until idle, it could short
      circuit the pinning for all active contexts.
      
      We introduce new engine vfuncs to pin and unpin the context
      respectively. The context is pinned at the start of the request, and
      only unpinned when the following request is retired (this ensures that
      the context is idle and coherent in main memory before we unpin it). We
      move the engine->last_context tracking into the retirement itself
      (rather than during request submission) in order to allow the submission
      to be reordered or unwound without undue difficultly.
      
      And finally an ulterior motive for unifying context handling was to
      prepare for mock requests.
      
      v2: Rename to last_retired_context, split out legacy_context tracking
      for MI_SET_CONTEXT.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
      e8a9c58f
  15. 15 12月, 2016 9 次提交
  16. 09 12月, 2016 1 次提交
    • I
      drm/i915/gen9: Fix PCODE polling during CDCLK change notification · a0b8a1fe
      Imre Deak 提交于
      commit 848496e5
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Wed Jul 13 16:32:03 2016 +0300
      
          drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
      
      increased the timeout to match the spec, but we still see a timeout on
      at least one SKL. A CDCLK change request following the failed one will
      succeed nevertheless.
      
      I could reproduce this problem easily by running kms_pipe_crc_basic in a
      loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
      the worst case - when the pre-emption happened right after calculating
      timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
      once which failed and so _wait_for() timed out. As opposed to this the
      spec says to keep retrying the request for at most a 3ms period.
      
      To fix this send the first request explicitly to guarantee that there is
      3ms between the first and last request. Though this matches the spec, I
      noticed that in rare cases this can still time out if we sent only a few
      requests (in the worst case 2) _and_ PCODE is busy for some reason even
      after a previous request and a 3ms delay. To work around this retry the
      polling with pre-emption disabled to maximize the number of requests.
      Also increase the timeout to 10ms to account for interrupts that could
      reduce the number of requests. With this change I couldn't trigger
      the problem.
      
      v2:
      - Use 1ms poll period instead of 10us. (Chris)
      v3:
      - Poll with pre-emption disabled to increase the number of request
        attempts. (Ville, Chris)
      - Factor out a helper to poll, it's also needed by the next patch.
      v4:
      - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
        reply is generic. (Ville)
      v5:
      - List the request specific timeout values as code comment. (Ville)
      v6:
      - Try the poll first with preemption enabled.
      - Add code comment about first request being queued by PCODE. (Art)
      - Add timeout_base_ms argument. (Ville)
      v7:
      - Clarify code comment about first queued request. (Chris)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Art Runyan <arthur.j.runyan@intel.com>
      Cc: <stable@vger.kernel.org> # v4.2- : 3b2c1710 : drm/i915: Wait up to 3ms
      Cc: <stable@vger.kernel.org> # v4.2-
      Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume")
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
      Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com
      a0b8a1fe
  17. 08 12月, 2016 2 次提交
  18. 07 12月, 2016 1 次提交