1. 01 2月, 2017 1 次提交
  2. 25 1月, 2017 1 次提交
    • C
      drm/i915: Move atomic state free from out of fence release · 6f0f02dc
      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>
      (cherry picked from commit eb955eee)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      6f0f02dc
  3. 23 1月, 2017 1 次提交
  4. 19 1月, 2017 4 次提交
  5. 18 1月, 2017 1 次提交
  6. 13 1月, 2017 2 次提交
  7. 11 1月, 2017 3 次提交
  8. 10 1月, 2017 5 次提交
  9. 09 1月, 2017 1 次提交
  10. 07 1月, 2017 2 次提交
  11. 06 1月, 2017 1 次提交
  12. 05 1月, 2017 2 次提交
  13. 02 1月, 2017 1 次提交
  14. 31 12月, 2016 4 次提交
  15. 26 12月, 2016 1 次提交
  16. 24 12月, 2016 2 次提交
  17. 22 12月, 2016 1 次提交
  18. 20 12月, 2016 2 次提交
    • I
      drm/i915/gen9: Fix PCODE polling during CDCLK change notification · 2c7d0602
      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
      (cherry picked from commit a0b8a1fe)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      2c7d0602
    • R
      drm/i915: Expand is_lp backwards to gen8_lp and gen7_lp. · 8727dc09
      Rodrigo Vivi 提交于
      Valleyview/Baytrail (gen7_lp) and Cherryview/Braswell (gen8_lp)
      are both Atom platforms like Broxton/Apollolake and Geminilake.
      
      So let's expand this is_lp back to these platforms and
      create the IS_LP(dev_priv) so we can start simplifying a bit
      our if/else for platform lists.
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1482096988-400-1-git-send-email-rodrigo.vivi@intel.com
      8727dc09
  19. 19 12月, 2016 3 次提交
  20. 17 12月, 2016 1 次提交
  21. 15 12月, 2016 1 次提交