drivers/gpu/drm/msm/msm_ringbuffer.h
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/msm/msm_ringbuffer.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/msm/msm_ringbuffer.h- Extension
.h- Size
- 3878 bytes
- Lines
- 143
- 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
drm/gpu_scheduler.hmsm_drv.h
Detected Declarations
struct msm_gpu_submit_statsstruct msm_rbmemptrsstruct msm_cp_statestruct msm_ringbufferfunction OUT_RING
Annotated Snippet
struct msm_gpu_submit_stats {
u64 cpcycles_start;
u64 cpcycles_end;
u64 alwayson_start;
u64 alwayson_end;
};
#define MSM_GPU_SUBMIT_STATS_COUNT 64
struct msm_rbmemptrs {
volatile uint32_t rptr;
volatile uint32_t fence;
/* Introduced on A7xx */
volatile uint32_t bv_rptr;
volatile uint32_t bv_fence;
volatile struct msm_gpu_submit_stats stats[MSM_GPU_SUBMIT_STATS_COUNT];
volatile u64 ttbr0;
volatile u32 context_idr;
volatile u32 perfcntr_fence;
};
struct msm_cp_state {
uint64_t ib1_base, ib2_base;
uint32_t ib1_rem, ib2_rem;
};
struct msm_ringbuffer {
struct msm_gpu *gpu;
int id;
struct drm_gem_object *bo;
uint32_t *start, *end, *cur, *next;
/*
* The job scheduler for this ring.
*/
struct drm_gpu_scheduler sched;
/*
* List of in-flight submits on this ring. Protected by submit_lock.
*
* Currently just submits that are already written into the ring, not
* submits that are still in drm_gpu_scheduler's queues. At a later
* step we could probably move to letting drm_gpu_scheduler manage
* hangcheck detection and keep track of submit jobs that are in-
* flight.
*/
struct list_head submits;
spinlock_t submit_lock;
uint64_t iova;
uint32_t hangcheck_fence;
struct msm_rbmemptrs *memptrs;
uint64_t memptrs_iova;
struct msm_fence_context *fctx;
/**
* hangcheck_progress_retries:
*
* The number of extra hangcheck duration cycles that we have given
* due to it appearing that the GPU is making forward progress.
*
* For GPU generations which support progress detection (see.
* msm_gpu_funcs::progress()), if the GPU appears to be making progress
* (ie. the CP has advanced in the command stream, we'll allow up to
* DRM_MSM_HANGCHECK_PROGRESS_RETRIES expirations of the hangcheck timer
* before killing the job. But to detect progress we need two sample
* points, so the duration of the hangcheck timer is halved. In other
* words we'll let the submit run for up to:
*
* (DRM_MSM_HANGCHECK_DEFAULT_PERIOD / 2) * (DRM_MSM_HANGCHECK_PROGRESS_RETRIES + 1)
*/
int hangcheck_progress_retries;
/**
* last_cp_state: The state of the CP at the last call to gpu->progress()
*/
struct msm_cp_state last_cp_state;
/*
* preempt_lock protects preemption and serializes wptr updates against
* preemption. Can be aquired from irq context.
*/
spinlock_t preempt_lock;
/*
* Whether we skipped writing wptr and it needs to be updated in the
* future when the ring becomes current.
*/
Annotation
- Immediate include surface: `drm/gpu_scheduler.h`, `msm_drv.h`.
- Detected declarations: `struct msm_gpu_submit_stats`, `struct msm_rbmemptrs`, `struct msm_cp_state`, `struct msm_ringbuffer`, `function OUT_RING`.
- 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.