Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 9月, 2021 2 次提交
  3. 19 9月, 2021 1 次提交
  5. 15 9月, 2021 1 次提交
  7. 03 9月, 2021 1 次提交
  9. 05 8月, 2021 3 次提交
  11. 04 8月, 2021 1 次提交
  13. 28 7月, 2021 1 次提交
  15. 23 7月, 2021 2 次提交
  17. 18 6月, 2021 2 次提交
    • M
      drm/i915: Add support for explicit L3BANK steering · 31939274
      由 Matt Roper 提交于 
      Because Render Power Gating restricts us to just a single subslice as a
valid steering target for reads of multicast registers in a SUBSLICE
range, the default steering we setup at init may not lead to a suitable
target for L3BANK multicast register.  In cases where it does not, use
explicit runtime steering whenever an L3BANK multicast register is read.

While we're at it, let's simplify the function a little bit and drop its
support for gen10/CNL since no such platforms ever materialized for real
use.  Multicast register steering is already an area that causes enough
confusion; no need to complicate it with what's effectively dead code.

v2:
 - Use gt->uncore instead of gt->i915->uncore.  (Tvrtko)
 - Use {} as table terminator.  (Rodrigo)

v3:
 - L3bank fuse register is a disable mask rather than an enable mask.
   We need to invert it before use.  (CI)

v4:
 - L3bank ID goes in the subslice field, not the slice field.  (CI)

Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210617211425.1943662-4-matthew.d.roper@intel.com
      31939274
    • M
      drm/i915: Add GT support for multiple types of multicast steering · 0957e931
      由 Matt Roper 提交于 
      Although most of our multicast registers are replicated per-subslice, we
also have a small number of multicast registers that are replicated
per-l3 bank instead.  For both types of multicast registers we need to
make sure we steer reads of these registers to a valid instance.
Ideally we'd like to find a specific instance ID that would steer reads
of either type of multicast register to a valid instance (i.e., not
fused off and not powered down), but sometimes the combination of
part-specific fusing and the additional restrictions imposed by Render
Power Gating make it impossible to find any overlap between the set of
valid subslices and valid l3 banks.  This problem will become even more
noticeable on our upcoming platforms since they will be adding
additional types of multicast registers with new types of replication
and rules for finding valid instances for reads.

To handle this we'll continue to pick a suitable subslice instance at
driver startup and program this as the default (sliceid,subsliceid)
setting in the steering control register (0xFDC).  In cases where we
need to read another type of multicast GT register, but the default
subslice steering would not correspond to a valid instance, we'll
explicitly re-steer the single read to a valid value, perform the read,
and then reset the steering to it's "subslice" default.

This patch adds the general functionality to prepare for this explicit
steering of other multicast register types.  We'll plug L3 bank steering
into this in the next patch, and then add additional types of multicast
registers when the support for our next upcoming platform arrives.

v2:
 - Use entry->end==0 as table terminator.  (Rodrigo)
 - Grab forcewake in wa_list_verify() now that we're using accessors
   that assume forcewake is already held.

v3:
 - Fix loop condition when iterating over steering range tables.
   (Rodrigo)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210617211425.1943662-3-matthew.d.roper@intel.com
      0957e931
  19. 17 6月, 2021 1 次提交
  21. 06 6月, 2021 1 次提交
  23. 02 6月, 2021 1 次提交
  25. 26 3月, 2021 1 次提交
    • T
      drm/i915: Request watchdog infrastructure · 9b4d0598
      由 Tvrtko Ursulin 提交于 
      Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activated due yet missing ability to actually
configure the timer.

Outline of the basic operation:

A timer is started when request is ready for execution. If the request
completes (retires) before the timer fires, timer is cancelled and nothing
further happens.

If the timer fires request is added to a lockless list and worker queued.
Purpose of this is twofold: a) It allows request cancellation from a more
friendly context and b) coalesces multiple expirations into a single event
of consuming the list.

Worker locklessly consumes the list of expired requests and cancels them
all using previous added i915_request_cancel().

Associated timeout value is stored in rq->context.watchdog.timeout_us.

v2:
 * Log expiration.

v3:
 * Include more information about user timeline in the log message.

v4:
 * Remove obsolete comment and fix formatting. (Matt)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324121335.2307063-6-tvrtko.ursulin@linux.intel.com
      9b4d0598
  27. 25 3月, 2021 4 次提交
  29. 24 12月, 2020 1 次提交
  31. 06 10月, 2020 1 次提交
  33. 07 9月, 2020 2 次提交
  35. 09 7月, 2020 4 次提交
  37. 07 7月, 2020 1 次提交
  39. 26 5月, 2020 1 次提交
  41. 01 5月, 2020 1 次提交
  43. 30 4月, 2020 1 次提交
    • C
      drm/i915/gt: Keep a no-frills swappable copy of the default context state · be1cb55a
      由 Chris Wilson 提交于 
      We need to keep the default context state around to instantiate new
contexts (aka golden rendercontext), and we also keep it pinned while
the engine is active so that we can quickly reset a hanging context.
However, the default contexts are large enough to merit keeping in
swappable memory as opposed to kernel memory, so we store them inside
shmemfs. Currently, we use the normal GEM objects to create the default
context image, but we can throw away all but the shmemfs file.

This greatly simplifies the tricky power management code which wants to
run underneath the normal GT locking, and we definitely do not want to
use any high level objects that may appear to recurse back into the GT.
Though perhaps the primary advantage of the complex GEM object is that
we aggressively cache the mapping, but here we are recreating the
vm_area everytime time we unpark. At the worst, we add a lightweight
cache, but first find a microbenchmark that is impacted.

Having started to create some utility functions to make working with
shmemfs objects easier, we can start putting them to wider use, where
GEM objects are overkill, such as storing persistent error state.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429172429.6054-1-chris@chris-wilson.co.uk
      be1cb55a
  45. 25 4月, 2020 1 次提交
  47. 27 3月, 2020 1 次提交
  49. 13 3月, 2020 1 次提交
  51. 22 2月, 2020 1 次提交
  53. 21 2月, 2020 1 次提交
  55. 31 1月, 2020 1 次提交