dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 00/15] i915: Explicit handling of multicast registers
@ 2022-03-30 23:28 Matt Roper
  2022-03-30 23:28 ` [PATCH 01/15] drm/i915/gen8: Create separate reg definitions for new MCR registers Matt Roper
                   ` (14 more replies)
  0 siblings, 15 replies; 24+ messages in thread
From: Matt Roper @ 2022-03-30 23:28 UTC (permalink / raw)
  To: intel-gfx
  Cc: Lucas De Marchi, Daniele Ceraolo Spurio, dri-devel, Tvrtko Ursulin

Multicast/replicated (MCR) registers on Intel hardware are a purely
GT-specific concept.  Rather than leaving MCR register handling spread
across several places throughout the driver (intel_uncore.c, intel_gt.c,
etc.) with confusing combinations of handler functions living in
different namespaces, let's consolidate it all into a single place
(intel_gt_mcr.c) and provide a more consistent and clearly-documented
interface for the rest of the driver to access such registers:

 * intel_gt_mcr_read -- unicast read from specific instance
 * intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated
   instance
 * intel_gt_mcr_unicast_write -- unicast write to specific instance
 * intel_gt_mcr_multicast_write[_fw] -- multicast write to all instances

To ensure these new interfaces are used for all accesses to MCR
registers (rather than relying on the implicit and possibly incorrect
semantics of our regular mmio accessors), we'll also promote multicast
registers to a unique type within the driver (i915_mcr_reg_t rather than
the traditional i915_reg_t).  This will let the compiler help us catch
places where the code is trying to perform a non-MCR-aware MMIO
operation on an MCR register.

Finally, we'll implement new guidance from our hardware architects that
we should steer every undirected access to MCR registers (including
registers in GSLICE/DSS MCR ranges) at the time of access on Xe_HP,
rather than relying on a default steering target programmed at driver
initialization time.

One aspect of this series that I'm not super happy with is the handling
of mixed lists MCR and non-MCR registers that we have in a few places
(e.g., the various whitelists used by perf, GVT, etc.).  Since we're not
actually accessing the registers in those spots, just listing them out
so their MMIO offsets can be used for comparison, for now I've
effectively cast the MCR registers on those lists back to i915_reg_t
type so that the compiler doesn't complain about seeing incompatible
i915_mcr_reg_t elements in a list that's supposed to be i915_reg_t.  We
may want to think about better ways to handle heterogeneous lists of MCR
and non-MCR registers, or possibly just convert those to lists of u32
offsets since we're not actually using them to perform MMIO accesses.


Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>


Matt Roper (15):
  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/xehp: Check for faults on all mslices
  drm/i915: Drop duplicated definition of XEHPSDV_FLAT_CCS_BASE_ADDR
  drm/i915: Move XEHPSDV_TILE0_ADDR_RANGE to GT register header
  drm/i915: Define MCR registers explicitly
  drm/i915/gt: Move multicast register handling to a dedicated file
  drm/i915/gt: Cleanup interface for MCR operations
  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/xehp: Eliminate shared/implicit steering

 drivers/gpu/drm/i915/Makefile                 |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c    |   4 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c     |  34 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c          |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt.c            | 303 ++---------
 drivers/gpu/drm/i915/gt/intel_gt.h            |  15 -
 drivers/gpu/drm/i915/gt/intel_gt_debugfs.c    |   3 +-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c        | 506 ++++++++++++++++++
 drivers/gpu/drm/i915/gt/intel_gt_mcr.h        |  34 ++
 drivers/gpu/drm/i915/gt/intel_gt_regs.h       | 153 +++---
 drivers/gpu/drm/i915/gt/intel_gt_types.h      |   1 +
 drivers/gpu/drm/i915/gt/intel_gtt.c           |  44 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h           |   2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c           |   6 +-
 drivers/gpu/drm/i915/gt/intel_mocs.c          |  12 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c   |   3 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 473 ++++++++--------
 .../gpu/drm/i915/gt/selftest_workarounds.c    |   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c    |  61 ++-
 .../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/cmd_parser.c         |   2 +-
 drivers/gpu/drm/i915/gvt/handlers.c           |  19 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c       |  16 +-
 drivers/gpu/drm/i915/i915_perf.c              |   2 +-
 drivers/gpu/drm/i915/i915_reg.h               |   6 -
 drivers/gpu/drm/i915/i915_reg_defs.h          |   9 +
 drivers/gpu/drm/i915/intel_pm.c               |  20 +-
 drivers/gpu/drm/i915/intel_uncore.c           | 112 ----
 drivers/gpu/drm/i915/intel_uncore.h           |   8 -
 30 files changed, 1059 insertions(+), 816 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_mcr.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_mcr.h

-- 
2.34.1


^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2022-04-07 12:30 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-30 23:28 [PATCH 00/15] i915: Explicit handling of multicast registers Matt Roper
2022-03-30 23:28 ` [PATCH 01/15] drm/i915/gen8: Create separate reg definitions for new MCR registers Matt Roper
2022-03-30 23:28 ` [PATCH 02/15] drm/i915/xehp: " Matt Roper
2022-03-30 23:28 ` [PATCH 03/15] drm/i915/gt: Drop a few unused register definitions Matt Roper
2022-03-30 23:28 ` [PATCH 04/15] drm/i915/gt: Correct prefix on a few registers Matt Roper
2022-03-30 23:28 ` [PATCH 05/15] drm/i915/xehp: Check for faults on all mslices Matt Roper
2022-03-30 23:28 ` [PATCH 06/15] drm/i915: Drop duplicated definition of XEHPSDV_FLAT_CCS_BASE_ADDR Matt Roper
2022-03-30 23:28 ` [PATCH 07/15] drm/i915: Move XEHPSDV_TILE0_ADDR_RANGE to GT register header Matt Roper
2022-03-30 23:28 ` [PATCH 08/15] drm/i915: Define MCR registers explicitly Matt Roper
2022-03-30 23:28 ` [PATCH 09/15] drm/i915/gt: Move multicast register handling to a dedicated file Matt Roper
2022-03-30 23:28 ` [PATCH 10/15] drm/i915/gt: Cleanup interface for MCR operations Matt Roper
2022-03-30 23:28 ` [PATCH 11/15] drm/i915/gt: Always use MCR functions on multicast registers Matt Roper
2022-03-30 23:28 ` [PATCH 12/15] drm/i915/guc: Handle save/restore of MCR registers explicitly Matt Roper
2022-03-30 23:28 ` [PATCH 13/15] drm/i915/gt: Add MCR-specific workaround initializers Matt Roper
2022-03-30 23:28 ` [PATCH 14/15] drm/i915: Define multicast registers as a new type Matt Roper
2022-04-01  7:55   ` [Intel-gfx] " Tvrtko Ursulin
2022-04-04 21:12     ` Matt Roper
2022-03-30 23:28 ` [PATCH 15/15] drm/i915/xehp: Eliminate shared/implicit steering Matt Roper
2022-03-31 17:35   ` [Intel-gfx] " Tvrtko Ursulin
2022-04-04 21:35     ` Matt Roper
2022-04-07 12:25       ` Tvrtko Ursulin
2022-04-01  8:34   ` Tvrtko Ursulin
2022-04-04 21:42     ` Matt Roper
2022-04-07 12:30       ` Tvrtko Ursulin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).