1. 20 12月, 2016 1 次提交
  2. 15 12月, 2016 9 次提交
  3. 05 12月, 2016 3 次提交
    • C
      drm/i915: Move priority bumping for flips earlier · 7a9e1025
      Chris Wilson 提交于
      David found another issue with priority bumping from mmioflips, where we
      are accessing the requests concurrently to them being retired and freed.
      Whilst we are skipping the dependency if has been submitted, that is not
      sufficient to stop the dependency from disappearing if another thread
      retires that request. To prevent we can either employ the struct_mutex (or a
      request mutex in the future) to serialise retiring before it is freed.
      Alternatively, we need to keep the dependencies alive using RCU whilst
      they are being accessed via the DFS.
      
      [ 1746.698111] general protection fault: 0000 [#1] PREEMPT SMP
      [ 1746.698305] Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core coretemp crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei i915 e1000e ptp pps_core i2c_hid
      [ 1746.698750] CPU: 1 PID: 6716 Comm: kworker/u8:2 Not tainted 4.9.0-rc6-CI-Nightly_816+ #1
      [ 1746.698871] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016
      [ 1746.699125] Workqueue: events_unbound intel_mmio_flip_work_func [i915]
      [ 1746.699266] task: ffff880260a5e800 task.stack: ffffc90000f6c000
      [ 1746.699361] RIP: 0010:[<ffffffffa006595d>]  [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
      [ 1746.699632] RSP: 0018:ffffc90000f6fcd8  EFLAGS: 00010206
      [ 1746.699724] RAX: dead0000000000f8 RBX: ffff8801f64b2bf0 RCX: ffff8801f64b2c10
      [ 1746.699842] RDX: dead000000000100 RSI: 0000000000000000 RDI: ffff8801f64b0458
      [ 1746.699972] RBP: ffffc90000f6fd68 R08: ffff88026488dc00 R09: 0000000000000002
      [ 1746.700090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000400
      [ 1746.700195] R13: ffffc90000f6fcf0 R14: ffff88020955aa40 R15: ffff88020955aa68
      [ 1746.700307] FS:  0000000000000000(0000) GS:ffff88026dc80000(0000) knlGS:0000000000000000
      [ 1746.700435] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1746.700532] CR2: 0000000002a69e90 CR3: 0000000002c07000 CR4: 00000000003406e0
      [ 1746.700635] Stack:
      [ 1746.700682]  ffff880260a5e880 ffffc90000f6fd50 ffffffff810af69a ffffc90000f6fd28
      [ 1746.700827]  ffff88020955a628 ffff8801e1eaebf0 0000000000000020 0000000000000000
      [ 1746.700947]  00000196af1edc96 ffff88025dfa4000 ffff8801f0b030a8 ffffc90000f6fcf0
      [ 1746.701071] Call Trace:
      [ 1746.701117]  [<ffffffff810af69a>] ? dequeue_entity+0x25a/0xb50
      [ 1746.701260]  [<ffffffffa00516be>] fence_set_priority+0x7e/0x80 [i915]
      [ 1746.701406]  [<ffffffffa0051a15>] i915_gem_object_wait_priority+0x85/0x160 [i915]
      [ 1746.701599]  [<ffffffffa008ccd7>] intel_mmio_flip_work_func+0x47/0x2b0 [i915]
      [ 1746.701717]  [<ffffffff81094c4d>] process_one_work+0x14d/0x470
      [ 1746.701809]  [<ffffffff81094fb3>] worker_thread+0x43/0x4e0
      [ 1746.701888]  [<ffffffff81094f70>] ? process_one_work+0x470/0x470
      [ 1746.701969]  [<ffffffff81094f70>] ? process_one_work+0x470/0x470
      [ 1746.702072]  [<ffffffff8109a4d5>] kthread+0xc5/0xe0
      [ 1746.702152]  [<ffffffff81771c59>] ? _raw_spin_unlock_irq+0x9/0x10
      [ 1746.702234]  [<ffffffff8109a410>] ? kthread_park+0x60/0x60
      [ 1746.702318]  [<ffffffff81772272>] ret_from_fork+0x22/0x30
      [ 1746.702387] Code: 89 42 08 48 8b 45 88 48 89 55 c0 4c 89 6d c8 4c 8d 70 d8 4d 8d 7e 28 4d 39 ef 74 72 49 8b 1e 48 8b 13 48 39 d3 48 8d 42 f8 74 3e <48> 8b 10 8b 52 38 41 39 d4 7e 26 48 8b 50 30 48 8b 78 28 48 8d
      [ 1746.702921] RIP  [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
      Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.703027]  RSP <ffffc90000f6fcd8>
      
      Fixes: 27745e82 ("drm/i915/execlists: Use a local lock for dfs_link access")
      Fixes: 9a151987 ("drm/i915: Add execution priority boosting for mmioflips")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: David Weinehall <david.weinehall@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161128143649.4289-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      (cherry picked from commit 92117f0b)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      7a9e1025
    • V
      drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time · 1f3dc3e3
      Ville Syrjälä 提交于
      Looks like we're only initializing dev_priv->atomic_cdclk_freq
      at resume and commit times, not at init time. Let's do that as
      well.
      
      We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in
      hsw_compute_linetime_wm() on account of populating
      intel_state->cdclk from dev_priv->atomic_cdclk_freq.
      Previously we were mispopulating intel_state->cdclk with
      dev_priv->cdclk_freq which always had a proper value at init
      time and hence the WARN_ON() didn't trigger.
      
      Cc: <stable@vger.kernel.org> # 4.6+: 14676ec6 drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
      Cc: <stable@vger.kernel.org> # 4.6+
      Cc: Matthew Auld <matthew.auld@intel.com>
      Reported-by: NMatthew Auld <matthew.auld@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902
      Fixes: 14676ec6 ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1480428837-4207-1-git-send-email-ville.syrjala@linux.intel.comTested-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      (cherry picked from commit 6a259b1f)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      1f3dc3e3
    • V
      drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things · 14676ec6
      Ville Syrjälä 提交于
      When we end up not recomputing the cdclk, we need to populate
      intel_state->cdclk with the "atomic_cdclk_freq" instead of the
      current cdclk_freq. When no pipes are active, the actual cdclk_freq
      may be lower than what the configuration of the planes and
      pipes would require from the point of view of the software state.
      
      This fixes bogus WARNS from skl_max_scale() which is trying to check
      the plane software state against the cdclk frequency. So any time
      it got called during DPMS off for instance, we might have tripped
      the warn if the current mode would have required a higher than
      minimum cdclk.
      
      v2: Drop the dev_cdclk stuff (Maarten)
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Mika Kahola <mika.kahola@intel.com>
      Cc: bruno.pagani@ens-lyon.org
      Cc: Daniel J Blueman <daniel.blueman@gmail.com>
      Cc: Paul Bolle <pebolle@tiscali.nl>
      Cc: Joseph Yasi <joe.yasi@gmail.com>
      Tested-by: NPaul Bolle <pebolle@tiscali.nl>
      Tested-by: Joseph Yasi <joe.yasi@gmail.com> (v1)
      Cc: <stable@vger.kernel.org> # v4.6+
      Fixes: 1a617b77 ("drm/i915: Keep track of the cdclk as if all crtc's were active.")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com
      (cherry picked from commit e0ca7a6b)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      14676ec6
  4. 30 11月, 2016 1 次提交
  5. 19 11月, 2016 1 次提交
  6. 18 11月, 2016 2 次提交
  7. 17 11月, 2016 13 次提交
  8. 15 11月, 2016 10 次提交