Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v3 00/14] Explicit MCR handling and MTL steering
Date: Fri, 14 Oct 2022 16:02:25 -0700	[thread overview]
Message-ID: <20221014230239.1023689-1-matthew.d.roper@intel.com> (raw)

Steering of multicast/replicated registers becomes a bit more
complicated on Meteor Lake.  Whereas previously the control register we
used to manage the steering was only used by our driver[*], software's
control of steering has now been consolidated with the controls for
various other hardware/firmware agents into a single register.  We can
no longer utilize pre-programmed implicit steering since other firmware
agents may change the steering target and not restore it afterward;
we'll need to explicitly steer all types of MCR registers (including the
GSLICE/COMPUTE/DSS ranges that have been handled implicitly in the
past).  Furthermore, since multiple agents will now be sharing a single
steering control register, races are possible.  To address this, the
hardware adds a new MCR semaphore register which is supposed to be used
to temporarily lock the steering while performing MCR operations.

It's going to become important for us to handle accesses of multicast
registers very explicitly going forward.  This series provides some prep
work for that by updating our register definitions to clearly define
registers as either MCR or non-MCR and ensure that we're using the
intel_gt_mcr_*() functions rather than intel_uncore_*() when operating
on MCR registers.  By declaring MCR registers as a new C type (i.e., not
an i915_reg_t) we can have the compiler help us find any mistakes where
non-MCR functions are used on MCR registers and vice-versa.

This series also includes the general MCR steering tables and logic, but
does not yet introduce the support for the semaphore register that will
be used to coordinate steering updates with other agents; we'll provide
that support in a separate series once this preparation work has landed.


[*] This is a bit of an oversimplification; there are some hardware and
software debug tools that use the same MCR_SELECTOR register that i915
does and which could potentially re-steer MCR accesses behind our back.
E.g., simply using IGT's "intel_reg" tool to write the MCR_SELECTOR
register at the wrong time could interfere with driver operation.  But
given that these debug facilities require root privileges to run and are
only used by people intentionally debugging the driver or hardware, we
can ignore such races for real-world usage.

v2:
 - Add MCR handling of TLB invalidation registers (since they're in the
   GAM range, their read behavior behaves a bit more like unicast
   registers, but they should still be treated as MCR for writes).
 - Add MCR rmw and 'wait_for_reg' operations; these are only typically
   needed for GAM registers.
 - Switched a few more instances of MISCCPCTL, HALF_SLICE_CHICKEN3, and
   the fault registers over to MCR handling where appropriate.  (Bala)

v3:
 - Several checkpatch fixes
 - Update intel_gt_mcr_multicast_rmw() to the register's original value,
   aligning with the recent change to intel_uncore_rmw.
 - Move transition to MCR functions in mmio_invalidate_full() to the
   earlier patch that is dedicated to such changes.  (Bala)
 - Enforce stricter type checking on i915_mmio_reg_offset.  (Jani)
 - Drop several unnecessary GVT changes.
 - Use IP naming (Xe_LPG and Xe_LPM+) more consistently.
 - Update debug dumping of steering for MTL and beyond.
 - Handle the MULTICAST bit in the steering control register more
   explicitly on MTL and beyond where we no longer have implicit
   steering.  (Bala)

Matt Roper (14):
  drm/i915/gen8: Create separate reg definitions for new MCR registers
  drm/i915/xehp: Create separate reg definitions for new MCR registers
  drm/i915/gt: Drop a few unused register definitions
  drm/i915/gt: Correct prefix on a few registers
  drm/i915/gt: Add intel_gt_mcr_multicast_rmw() operation
  drm/i915/xehp: Check for faults on primary GAM
  drm/i915/gt: Add intel_gt_mcr_wait_for_reg_fw()
  drm/i915: Define MCR registers explicitly
  drm/i915/gt: Always use MCR functions on multicast registers
  drm/i915/guc: Handle save/restore of MCR registers explicitly
  drm/i915/gt: Add MCR-specific workaround initializers
  drm/i915: Define multicast registers as a new type
  drm/i915/xelpg: Add multicast steering
  drm/i915/xelpmp: Add multicast steering for media GT

 drivers/gpu/drm/i915/gt/intel_engine_cs.c     |   4 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c          |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt.c            | 126 ++++-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c        | 279 ++++++++--
 drivers/gpu/drm/i915/gt/intel_gt_mcr.h        |  24 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h       | 162 +++---
 drivers/gpu/drm/i915/gt/intel_gt_types.h      |   2 +
 drivers/gpu/drm/i915/gt/intel_gtt.c           |  22 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h           |   2 +-
 drivers/gpu/drm/i915/gt/intel_mocs.c          |  12 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 491 +++++++++++-------
 .../gpu/drm/i915/gt/intel_workarounds_types.h |   9 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c    |   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c    |  60 ++-
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c    |   8 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c     |  12 +-
 drivers/gpu/drm/i915/gvt/handlers.c           |   4 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c       |  14 +-
 drivers/gpu/drm/i915/i915_gpu_error.c         |  12 +-
 drivers/gpu/drm/i915/i915_pci.c               |   1 +
 drivers/gpu/drm/i915/i915_reg_defs.h          |  27 +-
 drivers/gpu/drm/i915/intel_gvt_mmio_table.c   |   2 +-
 drivers/gpu/drm/i915/intel_pm.c               |  18 +-
 23 files changed, 902 insertions(+), 395 deletions(-)

-- 
2.37.3


             reply	other threads:[~2022-10-14 23:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-14 23:02 Matt Roper [this message]
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 01/14] drm/i915/gen8: Create separate reg definitions for new MCR registers Matt Roper
2022-10-17 16:49   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 02/14] drm/i915/xehp: " Matt Roper
2022-10-17 16:49   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 03/14] drm/i915/gt: Drop a few unused register definitions Matt Roper
2022-10-17 16:50   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 04/14] drm/i915/gt: Correct prefix on a few registers Matt Roper
2022-10-17 16:51   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 05/14] drm/i915/gt: Add intel_gt_mcr_multicast_rmw() operation Matt Roper
2022-10-17 16:51   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 06/14] drm/i915/xehp: Check for faults on primary GAM Matt Roper
2022-10-17 16:52   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 07/14] drm/i915/gt: Add intel_gt_mcr_wait_for_reg_fw() Matt Roper
2022-10-17 16:52   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 08/14] drm/i915: Define MCR registers explicitly Matt Roper
2022-10-17 16:53   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 09/14] drm/i915/gt: Always use MCR functions on multicast registers Matt Roper
2022-10-17 16:53   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 10/14] drm/i915/guc: Handle save/restore of MCR registers explicitly Matt Roper
2022-10-17 16:54   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 11/14] drm/i915/gt: Add MCR-specific workaround initializers Matt Roper
2022-10-17 16:54   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 12/14] drm/i915: Define multicast registers as a new type Matt Roper
2022-10-17 16:59   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 13/14] drm/i915/xelpg: Add multicast steering Matt Roper
2022-10-17 17:01   ` Balasubramani Vivekanandan
2022-10-14 23:02 ` [Intel-gfx] [PATCH v3 14/14] drm/i915/xelpmp: Add multicast steering for media GT Matt Roper
2022-10-17 17:02   ` Balasubramani Vivekanandan
2022-10-14 23:20 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Explicit MCR handling and MTL steering (rev4) Patchwork
2022-10-14 23:21 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-10-14 23:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-10-15  1:03 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-10-17 16:17   ` Matt Roper
2022-10-17 17:40     ` Matt Roper
2022-10-17 18:10     ` Vudum, Lakshminarayana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221014230239.1023689-1-matthew.d.roper@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox