Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 07 9月, 2016 1 次提交
    • C
      drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE to SNB · fc2780b6
      由 Chris Wilson 提交于 
      According to the CI test machines, SNB also uses the
GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE value to report a bad
GEN6_PCODE_MIN_FREQ_TABLE request.

[  157.744641] WARNING: CPU: 5 PID: 9238 at
drivers/gpu/drm/i915/intel_pm.c:7760 sandybridge_pcode_write+0x141/0x200 [i915]
[  157.744642] Missing switch case (16) in gen6_check_mailbox_status
[  157.744642] Modules linked in: snd_hda_intel i915 ax88179_178a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me lpc_ich snd_pcm mei broadcom bcm_phy_lib tg3 ptp pps_core [last unloaded: vgem]
[  157.744658] CPU: 5 PID: 9238 Comm: drv_hangman Tainted: G     U  W 4.8.0-rc3-CI-CI_DRM_1589+ #1
[  157.744658] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
[  157.744659]  0000000000000000 ffff88011f093a98 ffffffff81426415 ffff88011f093ae8
[  157.744662]  0000000000000000 ffff88011f093ad8 ffffffff8107d2a6 00001e50810d3c9f
[  157.744663]  ffff880128680000 0000000000000008 0000000000000000 ffff88012868a650
[  157.744665] Call Trace:
[  157.744669]  [<ffffffff81426415>] dump_stack+0x67/0x92
[  157.744672]  [<ffffffff8107d2a6>] __warn+0xc6/0xe0
[  157.744673]  [<ffffffff8107d30a>] warn_slowpath_fmt+0x4a/0x50
[  157.744685]  [<ffffffffa0029831>] sandybridge_pcode_write+0x141/0x200 [i915]
[  157.744697]  [<ffffffffa002a88a>] intel_enable_gt_powersave+0x64a/0x1330 [i915]
[  157.744712]  [<ffffffffa006b4cb>] ? i9xx_emit_request+0x1b/0x80 [i915]
[  157.744725]  [<ffffffffa0055ed3>] __i915_add_request+0x1e3/0x370 [i915]
[  157.744738]  [<ffffffffa00428bd>] i915_gem_do_execbuffer.isra.16+0xced/0x1b80 [i915]
[  157.744740]  [<ffffffff811a232e>] ? __might_fault+0x3e/0x90
[  157.744752]  [<ffffffffa0043b72>] i915_gem_execbuffer2+0xc2/0x2a0 [i915]
[  157.744753]  [<ffffffff815485b7>] drm_ioctl+0x207/0x4c0
[  157.744765]  [<ffffffffa0043ab0>] ? i915_gem_execbuffer+0x360/0x360 [i915]
[  157.744767]  [<ffffffff810ea4ad>] ?  debug_lockdep_rcu_enabled+0x1d/0x20
[  157.744769]  [<ffffffff811fe09e>] do_vfs_ioctl+0x8e/0x680
[  157.744770]  [<ffffffff811a2377>] ? __might_fault+0x87/0x90
[  157.744771]  [<ffffffff811a232e>] ? __might_fault+0x3e/0x90
[  157.744773]  [<ffffffff810d3df2>] ?  trace_hardirqs_on_caller+0x122/0x1b0
[  157.744774]  [<ffffffff811fe6cc>] SyS_ioctl+0x3c/0x70
[  157.744776]  [<ffffffff8180fe69>] entry_SYSCALL_64_fastpath+0x1c/0xac

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97491
Fixes: 87660502 ("drm/i915/gen6+: Interpret mailbox error flags")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/20160826105926.3413-1-chris@chris-wilson.co.ukAcked-by: NMika Kuoppala <mika.kuoppala@intel.com>
(cherry picked from commit 7850d1c3)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      fc2780b6
  3. 22 8月, 2016 6 次提交
    • L
      drm/i915/skl: Ensure pipes with changed wms get added to the state · 762c60ab
      由 Lyude 提交于 
      If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-6-git-send-email-cpaul@redhat.com
(cherry picked from commit 05a76d3d)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      762c60ab
    • M
      drm/i915/gen9: Only copy WM results for changed pipes to skl_hw · 9909113c
      由 Matt Roper 提交于 
      When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw.  However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0.  Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.

This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes.  Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).

Changes since v1:
 - Add a function for copying a pipe's wm values
   (skl_copy_wm_for_pipe()) so we can reuse this later

Fixes: 734fa01f ("drm/i915/gen9: Calculate watermarks during atomic 'check' (v2)")
Fixes: 9b613022 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-4-git-send-email-cpaul@redhat.com
(cherry picked from commit 2722efb9)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      9909113c
    • L
      drm/i915/skl: Add support for the SAGV, fix underrun hangs · f4033726
      由 Lyude 提交于 
      Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV	with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.

This will still need additional work in the future: we shouldn't be
enabling the SAGV if any of the currently enabled planes can't enable WM
levels that introduce latencies >= 30 µs.

Changes since v11:
 - Add skl_can_enable_sagv()
 - Make sure we don't enable SAGV when not all planes can enable
   watermarks >= the SAGV engine block time. I was originally going to
   save this for later, but I recently managed to run into a machine
   that was having problems with a single pipe configuration + SAGV.
 - Make comparisons to I915_SKL_SAGV_NOT_CONTROLLED explicit
 - Change I915_SAGV_DYNAMIC_FREQ to I915_SAGV_ENABLE
 - Move printks outside of mutexes
 - Don't print error messages twice
Changes since v10:
 - Apparently sandybridge_pcode_read actually writes values and reads
   them back, despite it's misleading function name. This means we've
   been doing this mostly wrong and have been writing garbage to the
   SAGV control. Because of this, we no longer attempt to read the SAGV
   status during initialization (since there are no helpers for this).
 - mlankhorst noticed that this patch was breaking on some very early
   pre-release Skylake machines, which apparently don't allow you to
   disable the SAGV. To prevent machines from failing tests due to SAGV
   errors, if the first time we try to control the SAGV results in the
   mailbox indicating an invalid command, we just disable future attempts
   to control the SAGV state by setting dev_priv->skl_sagv_status to
   I915_SKL_SAGV_NOT_CONTROLLED and make a note of it in dmesg.
 - Move mutex_unlock() a little higher in skl_enable_sagv(). This
   doesn't actually fix anything, but lets us release the lock a little
   sooner since we're finished with it.
Changes since v9:
 - Only enable/disable sagv on Skylake
Changes since v8:
 - Add intel_state->modeset guard to the conditional for
   skl_enable_sagv()
Changes since v7:
 - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
   all we use it for anyway)
 - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
 - Fix a styling error that snuck past me
Changes since v6:
 - Protect skl_enable_sagv() with intel_state->modeset conditional in
   intel_atomic_commit_tail()
Changes since v5:
 - Don't use is_power_of_2. Makes things confusing
 - Don't use the old state to figure out whether or not to
   enable/disable the sagv, use the new one
 - Split the loop in skl_disable_sagv into it's own function
 - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
Changes since v4:
 - Use is_power_of_2 against active_crtcs to check whether we have > 1
   pipe enabled
 - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
   enabled
 - Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
 - Use time_before() to compare timeout to jiffies
Changes since v2:
 - Really apply minor style nitpicks to patch this time
Changes since v1:
 - Added comments about this probably being one of the requirements to
   fixing Skylake's watermark issues
 - Minor style nitpicks from Matt Roper
 - Disable these functions on Broxton, since it doesn't have an SAGV
Signed-off-by: NLyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-3-git-send-email-cpaul@redhat.com
[mlankhorst: ENOSYS -> ENXIO, whitespace fixes]

(cherry picked from commit 656d1b89)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      f4033726
    • L
      drm/i915/gen6+: Interpret mailbox error flags · 5bc6abe7
      由 Lyude 提交于 
      In order to add proper support for the SAGV, we need to be able to know
what the cause of a failure to change the SAGV through the pcode mailbox
was. The reasoning for this is that some very early pre-release Skylake
machines don't actually allow you to control the SAGV on them, and
indicate an invalid mailbox command was sent.

This also might come in handy in the future for debugging.

Changes since v1:
 - Add functions for interpreting gen6 mailbox error codes along with
   gen7+ error codes, and actually interpret those codes properly
 - Renamed patch to reflect new behavior
Signed-off-by: NLyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-2-git-send-email-cpaul@redhat.com
[mlankhorst: -ENOSYS -> -ENXIO for checkpatch]

(cherry picked from commit 87660502)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      5bc6abe7
    • M
      drm/i915/gen9: Drop invalid WARN() during data rate calculation · c7aca235
      由 Matt Roper 提交于 
      It's possible to have a non-zero plane mask and still wind up with a
total data rate of zero.  There are two cases where this can happen:

 * planes are active (from the KMS point of view), but are
   all fully clipped (positioned offscreen)
 * the only active plane on a CRTC is the cursor (which is handled
   independently and not counted into the general data rate computations

These are both valid display setups (although unusual), so we need to
drop the WARN().
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Testcase: kms_universal_planes.cursor-only-pipe-*
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466196140-16336-4-git-send-email-matthew.d.roper@intel.com
Cc: stable@vger.kernel.org #v4.7+
(cherry picked from commit 43aa7e87)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      c7aca235
    • M
      drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization (v2) · f4750a46
      由 Matt Roper 提交于 
      intel_state->active_crtcs is usually only initialized when doing a
modeset.  During our first atomic commit after boot, we're effectively
faking a modeset to sanitize the DDB/wm setup, so ensure that this field
gets initialized before use.

v2:
 - Don't clobber active_crtcs if our first commit really is a modeset
   (Maarten)
 - Grab connection_mutex when faking a modeset during sanitization
   (Maarten)
Reported-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466196140-16336-2-git-send-email-matthew.d.roper@intel.com
Cc: stable@vger.kernel.org #v4.7+
(cherry picked from commit 1b54a880)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      f4750a46
  5. 11 8月, 2016 2 次提交
  7. 30 7月, 2016 1 次提交
  9. 15 7月, 2016 9 次提交
  11. 05 7月, 2016 1 次提交
  13. 04 7月, 2016 3 次提交
  15. 03 7月, 2016 1 次提交
  17. 02 7月, 2016 1 次提交
    • C
      drm/i915: Spin after waking up for an interrupt · f69a02c9
      由 Chris Wilson 提交于 
      When waiting for an interrupt (waiting for the engine to complete some
work), we know we are the only waiter to be woken on this engine. We also
know when the GPU has nearly completed our request (or at least started
processing it), so after being woken and we detect that the GPU is
active and working on our request, allow us the bottom-half (the first
waiter who wakes up to handle checking the seqno after the interrupt) to
spin for a very short while to reduce client latencies.

The impact is minimal, there was an improvement to the realtime-vs-many
clients case, but exporting the function proves useful later. However,
it is tempting to adjust irq_seqno_barrier to include the spin. The
problem is first ensuring that the "start-of-request" seqno is coherent
as we use that as our basis for judging when it is ok to spin. If we
could, spinning there could dramatically shorten some sleeps, and allow
us to make the barriers more conservative to handle missed seqno writes
on more platforms (all gen7+ are known to have the occasional issue, at
least).
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/1467390209-3576-7-git-send-email-chris@chris-wilson.co.uk
      f69a02c9
  19. 01 7月, 2016 2 次提交
  21. 30 6月, 2016 1 次提交
  23. 29 6月, 2016 1 次提交
  25. 21 6月, 2016 1 次提交
  27. 08 6月, 2016 10 次提交