drivers/gpu/drm/panthor/panthor_gem.h
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/panthor/panthor_gem.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/panthor/panthor_gem.h- Extension
.h- Size
- 9422 bytes
- Lines
- 333
- 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
drm/drm_gem.hdrm/drm_mm.hlinux/iosys-map.hlinux/rwsem.h
Detected Declarations
struct panthor_vmstruct panthor_gem_debugfsstruct panthor_gem_backingstruct panthor_gem_cpu_mapstruct panthor_gem_dev_mapstruct panthor_gem_objectstruct panthor_kernel_boenum panthor_debugfs_gem_state_flagsenum panthor_debugfs_gem_usage_flagsenum panthor_gem_reclaim_statefunction panthor_kernel_bo_gpuvafunction panthor_kernel_bo_sizefunction panthor_kernel_bo_vmapfunction panthor_kernel_bo_vunmap
Annotated Snippet
struct panthor_gem_debugfs {
/**
* @node: Node used to insert the object in the device-wide list of
* GEM objects, to display information about it through a DebugFS file.
*/
struct list_head node;
/** @creator: Information about the UM process which created the GEM. */
struct {
/** @creator.process_name: Group leader name in owning thread's process */
char process_name[TASK_COMM_LEN];
/** @creator.tgid: PID of the thread's group leader within its process */
pid_t tgid;
} creator;
/** @flags: Combination of panthor_debugfs_gem_usage_flags flags */
u32 flags;
};
/**
* struct panthor_gem_backing - GEM memory backing related data
*/
struct panthor_gem_backing {
/** @pages: Pages requested with drm_gem_get_pages() */
struct page **pages;
/** @pin_count: Number of active pin requests on this GEM */
refcount_t pin_count;
};
/**
* struct panthor_gem_cpu_map - GEM CPU mapping related data
*/
struct panthor_gem_cpu_map {
/** @vaddr: Address returned by vmap() */
void *vaddr;
/** @vaddr_use_count: Number of active vmap() requests on this GEM */
refcount_t vaddr_use_count;
/** @mmap_count: Number of active mmap() requests on this GEM */
refcount_t mmap_count;
};
/**
* struct panthor_gem_dev_map - GEM device mapping related data
*/
struct panthor_gem_dev_map {
/** @sgt: Device mapped sg_table for this GEM */
struct sg_table *sgt;
};
/**
* enum panthor_gem_reclaim_state - Reclaim state of a GEM object
*
* This is defined in descending reclaimability order and some part
* of the code depends on that.
*/
enum panthor_gem_reclaim_state {
/**
* @PANTHOR_GEM_UNUSED: GEM is currently unused
*
* This can happen when the GEM was previously vmap-ed, mmap-ed,
* and/or GPU mapped and got unmapped. Because pages are lazily
* returned to the shmem layer, we want to keep a list of such
* BOs, because they should be fairly easy to reclaim (no need
* to wait for GPU to be done, and no need to tear down user
* mappings either).
*/
PANTHOR_GEM_UNUSED,
/**
* @PANTHOR_GEM_MMAPPED: GEM is currently mmap-ed
*
* When a GEM has pages allocated and the mmap_count is > 0, the
* GEM is placed in the mmapped list. This comes right after
* unused because we can relatively easily tear down user mappings.
*/
PANTHOR_GEM_MMAPPED,
/**
* @PANTHOR_GEM_GPU_MAPPED_SINGLE_VM: GEM is GPU mapped to only one VM
*
* When a GEM is mapped to a single VM, reclaim requests have more
* chances to succeed, because we only need to synchronize against
* a single GPU context. This is more annoying than reclaiming
* mmap-ed pages still, because we have to wait for in-flight jobs
* to land, and we might not be able to acquire all necessary locks
* at reclaim time either.
Annotation
- Immediate include surface: `drm/drm_gem.h`, `drm/drm_mm.h`, `linux/iosys-map.h`, `linux/rwsem.h`.
- Detected declarations: `struct panthor_vm`, `struct panthor_gem_debugfs`, `struct panthor_gem_backing`, `struct panthor_gem_cpu_map`, `struct panthor_gem_dev_map`, `struct panthor_gem_object`, `struct panthor_kernel_bo`, `enum panthor_debugfs_gem_state_flags`, `enum panthor_debugfs_gem_usage_flags`, `enum panthor_gem_reclaim_state`.
- 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.