drivers/gpu/drm/amd/amdgpu/gfx_v11_0_3.c
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/amd/amdgpu/gfx_v11_0_3.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/amd/amdgpu/gfx_v11_0_3.c- Extension
.c- Size
- 3804 bytes
- Lines
- 111
- 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
amdgpu.hsoc21.hgc/gc_11_0_3_offset.hgc/gc_11_0_3_sh_mask.hivsrcid/gfx/irqsrcs_gfx_11_0_0.hsoc15.hsoc15d.hgfx_v11_0.h
Detected Declarations
function filesfunction gfx_v11_0_3_poison_consumption_handler
Annotated Snippet
REG_GET_FIELD(rlc_status0, RLC_RLCS_FED_STATUS_0, SDMA1_FED_ERR)) {
struct amdgpu_ras *ras = amdgpu_ras_get_context(adev);
ras->gpu_reset_flags |= AMDGPU_RAS_GPU_RESET_MODE2_RESET;
}
if (con && !amdgpu_ras_is_rma(adev))
amdgpu_ras_reset_gpu(adev);
}
return 0;
}
struct amdgpu_gfx_ras gfx_v11_0_3_ras = {
.rlc_gc_fed_irq = gfx_v11_0_3_rlc_gc_fed_irq,
.poison_consumption_handler = gfx_v11_0_3_poison_consumption_handler,
};
Annotation
- Immediate include surface: `amdgpu.h`, `soc21.h`, `gc/gc_11_0_3_offset.h`, `gc/gc_11_0_3_sh_mask.h`, `ivsrcid/gfx/irqsrcs_gfx_11_0_0.h`, `soc15.h`, `soc15d.h`, `gfx_v11_0.h`.
- Detected declarations: `function files`, `function gfx_v11_0_3_poison_consumption_handler`.
- 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.