drivers/gpu/drm/msm/msm_gem.h
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/msm/msm_gem.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/msm/msm_gem.h- Extension
.h- Size
- 15753 bytes
- Lines
- 500
- 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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
msm_mmu.hlinux/kref.hlinux/dma-resv.hdrm/drm_exec.hdrm/drm_gpuvm.hdrm/gpu_scheduler.hmsm_drv.h
Detected Declarations
struct msm_gem_vm_log_entrystruct msm_gem_vmstruct msm_fence_contextstruct msm_gem_vmastruct msm_gem_objectstruct msm_gem_statsstruct msm_gem_submitfunction msm_gem_lockfunction msm_gem_trylockfunction msm_gem_lock_interruptiblefunction msm_gem_unlockfunction msm_gem_lock_vm_and_objfunction msm_gem_assert_lockedfunction is_unpurgeablefunction is_purgeablefunction is_vunmapablefunction is_unevictablefunction msm_gem_submit_getfunction msm_gem_submit_put
Annotated Snippet
struct msm_gem_vm_log_entry {
const char *op;
uint64_t iova;
uint64_t range;
int queue_id;
};
/**
* struct msm_gem_vm - VM object
*
* A VM object representing a GPU (or display or GMU or ...) virtual address
* space.
*
* In the case of GPU, if per-process address spaces are supported, the address
* space is split into two VMs, which map to TTBR0 and TTBR1 in the SMMU. TTBR0
* is used for userspace objects, and is unique per msm_context/drm_file, while
* TTBR1 is the same for all processes. (The kernel controlled ringbuffer and
* a few other kernel controlled buffers live in TTBR1.)
*
* The GPU TTBR0 vm can be managed by userspace or by the kernel, depending on
* whether userspace supports VM_BIND. All other vm's are managed by the kernel.
* (Managed by kernel means the kernel is responsible for VA allocation.)
*
* Note that because VM_BIND allows a given BO to be mapped multiple times in
* a VM, and therefore have multiple VMA's in a VM, there is an extra object
* provided by drm_gpuvm infrastructure.. the drm_gpuvm_bo, which is not
* embedded in any larger driver structure. The GEM object holds a list of
* drm_gpuvm_bo, which in turn holds a list of msm_gem_vma. A linked vma
* holds a reference to the vm_bo, and drops it when the vma is unlinked.
* So we just need to call drm_gpuvm_bo_obtain_locked() to return a ref to an
* existing vm_bo, or create a new one. Once the vma is linked, the ref
* to the vm_bo can be dropped (since the vma is holding one).
*/
struct msm_gem_vm {
/** @base: Inherit from drm_gpuvm. */
struct drm_gpuvm base;
/**
* @sched: Scheduler used for asynchronous VM_BIND request.
*
* Unused for kernel managed VMs (where all operations are synchronous).
*/
struct drm_gpu_scheduler sched;
/**
* @prealloc_throttle: Used to throttle VM_BIND ops if too much pre-
* allocated memory is in flight.
*
* Because we have to pre-allocate pgtable pages for the worst case
* (ie. new mappings do not share any PTEs with existing mappings)
* we could end up consuming a lot of resources transiently. The
* prealloc_throttle puts an upper bound on that.
*/
struct {
/** @wait: Notified when preallocated resources are released */
wait_queue_head_t wait;
/**
* @in_flight: The # of preallocated pgtable pages in-flight
* for queued VM_BIND jobs.
*/
atomic_t in_flight;
} prealloc_throttle;
/**
* @mm: Memory management for kernel managed VA allocations
*
* Only used for kernel managed VMs, unused for user managed VMs.
*
* Protected by vm lock. See msm_gem_lock_vm_and_obj(), for ex.
*/
struct drm_mm mm;
/** @mmu: The mmu object which manages the pgtables */
struct msm_mmu *mmu;
/** @mmu_lock: Protects access to the mmu */
struct mutex mmu_lock;
/**
* @pid: For address spaces associated with a specific process, this
* will be non-NULL:
*/
struct pid *pid;
/** @last_fence: Fence for last pending work scheduled on the VM */
struct dma_fence *last_fence;
/** @log: A log of recent VM updates */
struct msm_gem_vm_log_entry *log;
Annotation
- Immediate include surface: `msm_mmu.h`, `linux/kref.h`, `linux/dma-resv.h`, `drm/drm_exec.h`, `drm/drm_gpuvm.h`, `drm/gpu_scheduler.h`, `msm_drv.h`.
- Detected declarations: `struct msm_gem_vm_log_entry`, `struct msm_gem_vm`, `struct msm_fence_context`, `struct msm_gem_vma`, `struct msm_gem_object`, `struct msm_gem_stats`, `struct msm_gem_submit`, `function msm_gem_lock`, `function msm_gem_trylock`, `function msm_gem_lock_interruptible`.
- Atlas domain: Driver Families / drivers/gpu.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
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.