Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 03 5月, 2012 1 次提交
  3. 18 4月, 2012 4 次提交
  5. 13 4月, 2012 4 次提交
    • 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: rc6 in sysfs · 0136db58
      由 Ben Widawsky 提交于 
      Merge rc6 information into the power group for our device. Until now the
i915 driver has not had any sysfs entries (aside from the connector
stuff enabled by drm core). Since it seems like we're likely to have
more in the future I created a new file for sysfs stubs, as well as the
rc6 sysfs functions which don't really belong elsewhere (perhaps
i915_suspend, but most of the stuff is in intel_display,c).

displays rc6 modes enabled (as a hex mask):
cat /sys/class/drm/card0/power/rc6_enable

displays #ms GPU has been in rc6 since boot:
cat /sys/class/drm/card0/power/rc6_residency_ms

displays #ms GPU has been in deep rc6 since boot:
cat /sys/class/drm/card0/power/rc6p_residency_ms

displays #ms GPU has been in deepest rc6 since boot:
cat /sys/class/drm/card0/power/rc6pp_residency_ms

Important note: I've seen on SNB that even when RC6 is *not* enabled the
rc6 register seems to have a random value in it. I can only guess at the
reason reason for this. Those writing tools that utilize this value need
to be careful and probably want to scrutinize the value very carefully.

v2: use common rc6 residency units to milliseconds for the other RC6 types

v3: don't create sysfs files for GEN <= 5
add a rc6_enable to show a mask of enabled rc6 types
use unmerge instead of remove for sysfs group
squash intel_enable_rc6() extraction into this patch

v4: rename sysfs files (Chris)

CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>f
CC: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: squash in the 64bit division fix by Chris Wilson.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0136db58
    • 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
    • C
      drm/i915: Reorganise rules for get_fence/put_fence · 9a5a53b3
      由 Chris Wilson 提交于 
      By simplifying the rules to calling get_fence when writing to the
through the GTT in a tiled manner, and calling put_fence before writing
to the object through the GTT in a linear manner, the code becomes
clearer and there is less chance of making a mistake.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[danvet: fixed up conflict with ppgtt code and spelling in a new
comment.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9a5a53b3
  7. 10 4月, 2012 4 次提交
  9. 02 4月, 2012 1 次提交
  11. 01 4月, 2012 1 次提交
  13. 29 3月, 2012 3 次提交
  15. 28 3月, 2012 3 次提交
  17. 27 3月, 2012 3 次提交
  19. 26 3月, 2012 1 次提交
  21. 24 3月, 2012 1 次提交
  23. 23 3月, 2012 2 次提交
  25. 21 3月, 2012 2 次提交
    • D
      drm/i915: bind objects to the global gtt only when needed · 74898d7e
      由 Daniel Vetter 提交于 
      And track the existence of such a binding similar to the aliasing
ppgtt case. Speeds up binding/unbinding in the common case where we
only need a ppgtt binding (which is accessed in a cpu coherent fashion
by the gpu) and no gloabl gtt binding (which needs uc writes for the
ptes).

This patch just puts the required tracking in place.

v2: Check that global gtt mappings exist in the error_state capture
code (with Chris Wilson's llc reloc patches batchbuffers are no longer
relocated as mappable in all situations, so this matters). Suggested
by Chris Wilson.

v3: Adapted to Chris' latest llc-reloc patches.

v4: Fix a bug in the i915 error state capture code noticed by Chris
Wilson.
Reviewed-and-tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      74898d7e
    • D
      drm/i915: split out dma mapping from global gtt bind/unbind functions · 74163907
      由 Daniel Vetter 提交于 
      Note that there's a functional change buried in this patch wrt the ilk
dmar workaround: We now only idle the gpu while tearing down the dmar
mappings, not while clearing the gtt. Keeping the current semantics
would have made for some really ugly code and afaik the issue is only
with the dmar unmapping that needs a fully idle gpu.
Reviewed-and-tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      74163907
  27. 19 3月, 2012 1 次提交
  29. 01 3月, 2012 4 次提交
  31. 28 2月, 2012 1 次提交
  33. 15 2月, 2012 3 次提交
    • C
      drm/i915: Record the position of the request upon error · ee4f42b1
      由 Chris Wilson 提交于 
      So that we can tally the request against the command sequence in the
ringbuffer, or merely jump to the interesting locations.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ee4f42b1
    • C
      drm/i915: Record the in-flight requests at the time of a hang · 52d39a21
      由 Chris Wilson 提交于 
      Being able to tally the list of outstanding requests with the sequence
of commands in the ringbuffer is often useful evidence with respect to
driver corruption.

Note that since this is the umpteenth per-ring data structure to be added
to the error state, I've coallesced the nearby loops (the ringbuffer and
batchbuffer) into a single structure along with the list of requests.  A
later task would be to refactor the ring register state into the same
structure.

v2: Fix pretty printing of requests so that they are parsed correctly by
intel_error_decode and use the 0x%08x format for seqno for consistency
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      52d39a21
    • C
      drm/i915: Record the tail at each request and use it to estimate the head · a71d8d94
      由 Chris Wilson 提交于 
      By recording the location of every request in the ringbuffer, we know
that in order to retire the request the GPU must have finished reading
it and so the GPU head is now beyond the tail of the request. We can
therefore provide a conservative estimate of where the GPU is reading
from in order to avoid having to read back the ring buffer registers
when polling for space upon starting a new write into the ringbuffer.

A secondary effect is that this allows us to convert
intel_ring_buffer_wait() to use i915_wait_request() and so consolidate
upon the single function to handle the complicated task of waiting upon
the GPU. A necessary precaution is that we need to make that wait
uninterruptible to match the existing conditions as all the callers of
intel_ring_begin() have not been audited to handle ERESTARTSYS
correctly.

By using a conservative estimate for the head, and always processing all
outstanding requests first, we prevent a race condition between using
the estimate and direct reads of I915_RING_HEAD which could result in
the value of the head going backwards, and the tail overflowing once
again. We are also careful to mark any request that we skip over in
order to free space in ring as consumed which provides a
self-consistency check.

Given sufficient abuse, such as a set of unthrottled GPU bound
cairo-traces, avoiding the use of I915_RING_HEAD gives a 10-20% boost on
Sandy Bridge (i5-2520m):
  firefox-paintball  18927ms -> 15646ms: 1.21x speedup
  firefox-fishtank   12563ms -> 11278ms: 1.11x speedup
which is a mild consolation for the performance those traces achieved from
exploiting the buggy autoreported head.

v2: Add a few more comments and make request->tail a conservative
estimate as suggested by Daniel Vetter.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: resolve conflicts with retirement defering and the lack of
the autoreport head removal (that will go in through -fixes).]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a71d8d94
  35. 14 2月, 2012 1 次提交
    • Y
      drm/i915: Fix race condition in accessing GMBUS · 8a8ed1f5
      由 Yufeng Shen 提交于 
      GMBUS has several ports and each has it's own corresponding
I2C adpater. When multiple I2C adapters call gmbus_xfer() at
the same time there is a race condition in using the underlying
GMBUS controller. Fixing this by adding a mutex lock when calling
gmbus_xfer().

v2: Moved gmbus_mutex below intel_gmbus and added comments.
Rebased to drm-intel-next-queued.
Signed-off-by: NYufeng Shen <miletus@chromium.org>
[danvet: Shortened the gmbus_mutex comment a bit and add the patch
revision comment to the commit message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8a8ed1f5