Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 5月, 2012 8 次提交
  3. 03 5月, 2012 2 次提交
  5. 13 4月, 2012 2 次提交
    • D
      drm/i915: re-init modeset hw state after gpu reset · f817586c
      由 Daniel Vetter 提交于 
      After a gpu reset we need to re-init some of the hw state we only
initialize when modeset is enabled, like rc6, hw contexts or render/GT
core clock gating and workaround register settings.

Note that this patch has a small change in the resume code:
- rc6 on gen6+ is only restored for the modeset case (for more
  consistency with other callsites). This is no problem because recent
  kernels refuse to load drm/i915 without kms on gen6+
- rc6/emon on ilk is only restored for the modeset case. This is no
  problem because rc6 is disabled by default on ilk, and ums on ilk
  has never really been a supported option outside of horrible rhel
  backports.

v2: Chris Wilson noticed that we not only fail to restore the clock
gating settings after gpu reset.

v3: Move the call to modeset_init_hw in _reset out of the
struct_mutext protected area - other callers don't hold it, too.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f817586c
    • B
      drm/i915: use semaphores for the display plane · 2911a35b
      由 Ben Widawsky 提交于 
      In theory this will have performance and power improvements. Performance
because we don't need to stall when the scanout BO is busy, and power
because we don't have to stall when the BO is busy (and the ring can
even go to sleep if the HW supports it).

v2:
squash 2 patches into 1 (me)
un-inline the enable_semaphores function (Daniel)
remove comment about SNB hangs from i915_gem_object_sync (Chris)
rename intel_enable_semaphores to i915_semaphore_is_enabled (me)
removed page flip comment; "no why" (Chris)

To address other comments from Daniel (irc):
update the comment to say 'vt-d is crap, don't enable semaphores'
  - I think you misinterpreted Chris' comment, it already exists.
checking out whether we can pageflip on the render ring on ivb (didn't
work on early silicon)
  - We don't want to enable workarounds for early silicon unless we have
    to.
  - I can't find any references in the docs about this.
optionally use it if the fb is already busy on the render ring
  - This should be how the code already worked, unless I am
    misunderstanding your meaning.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2911a35b
  7. 12 4月, 2012 1 次提交
  9. 10 4月, 2012 3 次提交
  11. 03 4月, 2012 1 次提交
  13. 02 4月, 2012 2 次提交
  15. 01 4月, 2012 1 次提交
  17. 29 3月, 2012 3 次提交
  19. 24 3月, 2012 1 次提交
  21. 23 3月, 2012 1 次提交
  23. 02 3月, 2012 1 次提交
  25. 12 2月, 2012 2 次提交
  27. 10 2月, 2012 1 次提交
  29. 09 2月, 2012 1 次提交
    • D
      drm/i915: swizzling support for snb/ivb · f691e2f4
      由 Daniel Vetter 提交于 
      We have to do this manually. Somebody had a Great Idea.

I've measured speed-ups just a few percent above the noise level
(below 5% for the best case), but no slowdows. Chris Wilson measured
quite a bit more (10-20% above the usual snb variance) on a more
recent and better tuned version of sna, but also recorded a few
slow-downs on benchmarks know for uglier amounts of snb-induced
variance.

v2: Incorporate Ben Widawsky's preliminary review comments and
elaborate a bit about the performance impact in the changelog.

v3: Add a comment as to why we don't need to check the 3rd memory
channel.

v4: Fixup whitespace.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f691e2f4
  31. 20 1月, 2012 4 次提交
  33. 18 1月, 2012 1 次提交
  35. 17 1月, 2012 2 次提交
  37. 14 1月, 2012 1 次提交
  39. 04 1月, 2012 1 次提交
    • K
      drm/i915: Clean up multi-threaded forcewake patch · c7dffff7
      由 Keith Packard 提交于 
      We learned that the ECOBUS register was inside the GT power well, and
so *did* need force wake to be read, so it gets removed from the list
of 'doesn't need force wake' registers.

That means the code reading ECOBUS after forcing the mt_force_wake
function to be called needs to use I915_READ_NOTRACE; it doesn't need
to do more force wake fun as it's already done it manually.

This also adds a comment explaining why the MT forcewake testing code
only needs to call mt_forcewake_get/put and not disable RC6 manually
-- the ECOBUS read will return 0 if the device is in RC6 and isn't
using MT forcewake, causing the test to work correctly.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      c7dffff7
  41. 17 12月, 2011 1 次提交