linux.git/drivers/gpu/drm/xe/xe_bb.c, branch v6.8

drm/xe: Extract MI_* instructions to their own header

2023-12-21T16:43:00+00:00

Extracting the common MI_* instructions that can be used with any engine
to their own header will make it easier as we add additional engine
instructions in upcoming patches.

Also, since the majority of GPU instructions (both MI and non-MI) have
a "length" field in bits 7:0 of the instruction header, a common define
is added for that.  Instruction-specific length fields are still defined
for special case instructions that have larger/smaller length fields.

v2:
 - Use "instr" instead of "inst" as the short form of "instruction"
   everywhere.  (Lucas)
 - Include xe_reg_defs.h instead of the i915 compat header.  (Lucas)

Reviewed-by: Lucas De Marchi 
Link: https://lore.kernel.org/r/20231016163449.1300701-12-matthew.d.roper@intel.com
Signed-off-by: Matt Roper 
Signed-off-by: Rodrigo Vivi

drm/xe: Use Xe assert macros instead of XE_WARN_ON macro

2023-12-21T16:41:08+00:00

The XE_WARN_ON macro maps to WARN_ON which is not justified
in many cases where only a simple debug check is needed.
Replace the use of the XE_WARN_ON macro with the new xe_assert
macros which relies on drm_*. This takes a struct drm_device
argument, which is one of the main changes in this commit. The
other main change is that the condition is reversed, as with
XE_WARN_ON a message is displayed if the condition is true,
whereas with xe_assert it is if the condition is false.

v2:
- Rebase
- Keep WARN splats in xe_wopcm.c (Matt Roper)

v3:
- Rebase

Signed-off-by: Francois Dugast 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi

drm/xe: standardize vm-less kernel submissions

2023-12-21T16:40:27+00:00

The current only submission in the driver that doesn't use a vm is the
WA setup. We still pass a vm structure (the migration one), but we don't
actually use it at submission time and we instead have an hack to use
GGTT for this particular engine.
Instead of special-casing the WA engine, we can skip providing a VM and
use that as selector for whether to use GGTT or PPGTT. As part of this
change, we can drop the special engine flag for the WA engine and switch
the WA submission to use the standard job functions instead of dedicated
ones.

v2: rebased on s/engine/exec_queue

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matthew Brost 
Reviewed-by: Matthew Brost 
Link: https://lore.kernel.org/r/20230822173334.1664332-4-daniele.ceraolospurio@intel.com
Signed-off-by: Rodrigo Vivi

drm/xe: Rename engine to exec_queue

2023-12-21T16:39:20+00:00

Engine was inappropriately used to refer to execution queues and it
also created some confusion with hardware engines. Where it applies
the exec_queue variable name is changed to q and comments are also
updated.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/162
Signed-off-by: Francois Dugast 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi

drm/xe: Prefer WARN() over BUG() to avoid crashing the kernel

2023-12-21T16:39:17+00:00

Replace calls to XE_BUG_ON() with calls XE_WARN_ON() which in turn calls
WARN() instead of BUG(). BUG() crashes the kernel and should only be
used when it is absolutely unavoidable in case of catastrophic and
unrecoverable failures, which is not the case here.

Signed-off-by: Francois Dugast 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi

drm/xe: Memory allocations are tile-based, not GT-based

2023-12-19T23:34:14+00:00

Since memory and address spaces are a tile concept rather than a GT
concept, we need to plumb tile-based handling through lots of
memory-related code.

Note that one remaining shortcoming here that will need to be addressed
before media GT support can be re-enabled is that although the address
space is shared between a tile's GTs, each GT caches the PTEs
independently in their own TLB and thus TLB invalidation should be
handled at the GT level.

v2:
 - Fix kunit test build.

Reviewed-by: Lucas De Marchi 
Link: https://lore.kernel.org/r/20230601215244.678611-13-matthew.d.roper@intel.com
Signed-off-by: Matt Roper 
Signed-off-by: Rodrigo Vivi

drm/xe: Add backpointer from gt to tile

2023-12-19T23:34:11+00:00

Rather than a backpointer to the xe_device, a GT should have a
backpointer to its tile (which can then be used to lookup the device if
necessary).

The gt_to_xe() helper macro (which moves from xe_gt.h to xe_gt_types.h)
can and should still be used to jump directly from an xe_gt to
xe_device.

v2:
 - Fix kunit test build
 - Move a couple changes to the previous patch. (Lucas)

Reviewed-by: Matt Atwood 
Reviewed-by: Lucas De Marchi 
Link: https://lore.kernel.org/r/20230601215244.678611-4-matthew.d.roper@intel.com
Signed-off-by: Matt Roper 
Signed-off-by: Rodrigo Vivi

drm/xe: Let primary and media GT share a kernel_bb_pool

2023-12-19T23:31:40+00:00

The media GT requires a valid gt->kernel_bb_pool during driver probe to
allocate the WA and NOOP batchbuffers used to record default context
images.  Dynamically allocate the bb_pools so that the primary and media
GT can use the same pool during driver init.

The media GT still shouldn't be need the USM pool, so only hook up the
kernel_bb_pool for now.

Cc: Maarten Lankhorst 
Reviewed-by: Matthew Brost 
Link: https://lore.kernel.org/r/20230410200229.2726648-1-matthew.d.roper@intel.com
Signed-off-by: Matt Roper 
Signed-off-by: Rodrigo Vivi

drm/xe: Adjust batchbuffer space warning when creating a job

2023-12-19T23:30:26+00:00

We should WARN (not BUG) when creating a job if the batchbuffer does not
have sufficient space and padding.  The hardware prefetch requirements
should also be considered.

Link: https://lore.kernel.org/r/20230329173334.4015124-3-matthew.d.roper@intel.com
Signed-off-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi

drm/xe: Include hardware prefetch buffer in batchbuffer allocations

2023-12-19T23:30:26+00:00

The hardware prefetches several cachelines of data from batchbuffers
before they are parsed.  This prefetching only stops when the parser
encounters an MI_BATCH_BUFFER_END instruction (or a nested
MI_BATCH_BUFFER_START), so we must ensure that there is enough padding
at the end of the batchbuffer to prevent the prefetcher from running
past the end of the allocation and potentially faulting.

Bspec: 45717
Link: https://lore.kernel.org/r/20230329173334.4015124-2-matthew.d.roper@intel.com
Signed-off-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi