drivers/gpu/drm/xe/xe_wa.c

Source file repositories/reference/linux-study-clean/drivers/gpu/drm/xe/xe_wa.c

File Facts

System
Linux kernel
Corpus path
drivers/gpu/drm/xe/xe_wa.c
Extension
.c
Size
36005 bytes
Lines
1025
Domain
Driver Families
Bucket
drivers/gpu
Inferred role
Driver Families: exported/initcall integration point
Status
integration implementation candidate

Why This File Exists

Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.

Dependency Surface

Detected Declarations

Annotated Snippet

// SPDX-License-Identifier: MIT
/*
 * Copyright © 2022 Intel Corporation
 */

#include "xe_wa.h"

#include <drm/drm_managed.h>
#include <kunit/visibility.h>
#include <linux/compiler_types.h>
#include <linux/fault-inject.h>

#include <generated/xe_device_wa_oob.h>
#include <generated/xe_wa_oob.h>

#include "regs/xe_engine_regs.h"
#include "regs/xe_gt_regs.h"
#include "regs/xe_guc_regs.h"
#include "regs/xe_regs.h"
#include "xe_device_types.h"
#include "xe_force_wake.h"
#include "xe_gt_types.h"
#include "xe_hw_engine_types.h"
#include "xe_mmio.h"
#include "xe_platform_types.h"
#include "xe_rtp.h"
#include "xe_sriov.h"
#include "xe_step.h"

/**
 * DOC: Hardware workarounds
 *
 * Hardware workarounds are register programming documented to be executed in
 * the driver that fall outside of the normal programming sequences for a
 * platform. There are some basic categories of workarounds, depending on
 * how/when they are applied:
 *
 * - LRC workarounds: workarounds that touch registers that are
 *   saved/restored to/from the HW context image. The list is emitted (via Load
 *   Register Immediate commands) once when initializing the device and saved in
 *   the default context. That default context is then used on every context
 *   creation to have a "primed golden context", i.e. a context image that
 *   already contains the changes needed to all the registers. See
 *   drivers/gpu/drm/xe/xe_lrc.c for default context handling.
 *
 * - Engine workarounds: the list of these WAs is applied whenever the specific
 *   engine is reset. It's also possible that a set of engine classes share a
 *   common power domain and they are reset together. This happens on some
 *   platforms with render and compute engines. In this case (at least) one of
 *   them need to keeep the workaround programming: the approach taken in the
 *   driver is to tie those workarounds to the first compute/render engine that
 *   is registered.  When executing with GuC submission, engine resets are
 *   outside of kernel driver control, hence the list of registers involved is
 *   written once, on engine initialization, and then passed to GuC, that
 *   saves/restores their values before/after the reset takes place. See
 *   drivers/gpu/drm/xe/xe_guc_ads.c for reference.
 *
 * - GT workarounds: the list of these WAs is applied whenever these registers
 *   revert to their default values: on GPU reset, suspend/resume [1]_, etc.
 *
 * - Register whitelist: some workarounds need to be implemented in userspace,
 *   but need to touch privileged registers. The whitelist in the kernel
 *   instructs the hardware to allow the access to happen. From the kernel side,
 *   this is just a special case of a MMIO workaround (as we write the list of
 *   these to/be-whitelisted registers to some special HW registers).
 *
 * - Workaround batchbuffers: buffers that get executed automatically by the
 *   hardware on every HW context restore. These buffers are created and
 *   programmed in the default context so the hardware always go through those
 *   programming sequences when switching contexts. The support for workaround
 *   batchbuffers is enabled via these hardware mechanisms:
 *
 *   #. INDIRECT_CTX (also known as **mid context restore bb**): A batchbuffer
 *      and an offset are provided in the default context, pointing the hardware
 *      to jump to that location when that offset is reached in the context
 *      restore.  When a context is being restored, this is executed after the
 *      ring context, in the middle (or beginning) of the engine context image.
 *
 *   #. BB_PER_CTX_PTR (also known as **post context restore bb**): A
 *      batchbuffer is provided in the default context, pointing the hardware to
 *      a buffer to continue executing after the engine registers are restored
 *      in a context restore sequence.
 *
 *   Below is the timeline for a context restore sequence:
 *
 *   .. code::
 *
 *                        INDIRECT_CTX_OFFSET
 *                   |----------->|
 *      .------------.------------.-------------.------------.--------------.-----------.

Annotation

Implementation Notes