drivers/gpu/drm/xe/xe_tile.c
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/xe/xe_tile.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/xe/xe_tile.c- Extension
.c- Size
- 7339 bytes
- Lines
- 248
- Domain
- Driver Families
- Bucket
- drivers/gpu
- Inferred role
- Driver Families: implementation source
- Status
- source 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.
- 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.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/fault-inject.hdrm/drm_managed.hdrm/drm_pagemap_util.hxe_bo.hxe_device_types.hxe_ggtt.hxe_memirq.hxe_migrate.hxe_pcode.hxe_sa.hxe_svm.hxe_tile.hxe_tile_sysfs.hxe_ttm_vram_mgr.hxe_vram.hxe_vram_types.hxe_wa.h
Detected Declarations
function xe_tile_allocfunction xe_tile_alloc_vramfunction xe_tile_init_earlyfunction xe_tile_init_noallocfunction xe_tile_initfunction xe_tile_migrate_waitfunction xe_tile_local_pagemap
Annotated Snippet
// SPDX-License-Identifier: MIT
/*
* Copyright © 2023 Intel Corporation
*/
#include <linux/fault-inject.h>
#include <drm/drm_managed.h>
#include <drm/drm_pagemap_util.h>
#include "xe_bo.h"
#include "xe_device_types.h"
#include "xe_ggtt.h"
#include "xe_memirq.h"
#include "xe_migrate.h"
#include "xe_pcode.h"
#include "xe_sa.h"
#include "xe_svm.h"
#include "xe_tile.h"
#include "xe_tile_sysfs.h"
#include "xe_ttm_vram_mgr.h"
#include "xe_vram.h"
#include "xe_vram_types.h"
#include "xe_wa.h"
/**
* DOC: Multi-tile Design
*
* Different vendors use the term "tile" a bit differently, but in the Intel
* world, a 'tile' is pretty close to what most people would think of as being
* a complete GPU. When multiple GPUs are placed behind a single PCI device,
* that's what is referred to as a "multi-tile device." In such cases, pretty
* much all hardware is replicated per-tile, although certain responsibilities
* like PCI communication, reporting of interrupts to the OS, etc. are handled
* solely by the "root tile." A multi-tile platform takes care of tying the
* tiles together in a way such that interrupt notifications from remote tiles
* are forwarded to the root tile, the per-tile vram is combined into a single
* address space, etc.
*
* In contrast, a "GT" (which officially stands for "Graphics Technology") is
* the subset of a GPU/tile that is responsible for implementing graphics
* and/or media operations. The GT is where a lot of the driver implementation
* happens since it's where the hardware engines, the execution units, and the
* GuC all reside.
*
* Historically most Intel devices were single-tile devices that contained a
* single GT. PVC is an example of an Intel platform built on a multi-tile
* design (i.e., multiple GPUs behind a single PCI device); each PVC tile only
* has a single GT. In contrast, platforms like MTL that have separate chips
* for render and media IP are still only a single logical GPU, but the
* graphics and media IP blocks are each exposed as a separate GT within that
* single GPU. This is important from a software perspective because multi-GT
* platforms like MTL only replicate a subset of the GPU hardware and behave
* differently than multi-tile platforms like PVC where nearly everything is
* replicated.
*
* Per-tile functionality (shared by all GTs within the tile):
* - Complete 4MB MMIO space (containing SGunit/SoC registers, GT
* registers, display registers, etc.)
* - Global GTT
* - VRAM (if discrete)
* - Interrupt flows
* - Migration context
* - kernel batchbuffer pool
* - Primary GT
* - Media GT (if media version >= 13)
*
* Per-GT functionality:
* - GuC
* - Hardware engines
* - Programmable hardware units (subslices, EUs)
* - GSI subset of registers (multiple copies of these registers reside
* within the complete MMIO space provided by the tile, but at different
* offsets --- 0 for render, 0x380000 for media)
* - Multicast register steering
* - TLBs to cache page table translations
* - Reset capability
* - Low-level power management (e.g., C6)
* - Clock frequency
* - MOCS and PAT programming
*/
/**
* xe_tile_alloc - Perform per-tile memory allocation
* @tile: Tile to perform allocations for
*
* Allocates various per-tile data structures using DRM-managed allocations.
* Does not touch the hardware.
*
* Returns -ENOMEM if allocations fail, otherwise 0.
Annotation
- Immediate include surface: `linux/fault-inject.h`, `drm/drm_managed.h`, `drm/drm_pagemap_util.h`, `xe_bo.h`, `xe_device_types.h`, `xe_ggtt.h`, `xe_memirq.h`, `xe_migrate.h`.
- Detected declarations: `function xe_tile_alloc`, `function xe_tile_alloc_vram`, `function xe_tile_init_early`, `function xe_tile_init_noalloc`, `function xe_tile_init`, `function xe_tile_migrate_wait`, `function xe_tile_local_pagemap`.
- Atlas domain: Driver Families / drivers/gpu.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.