drivers/gpu/drm/panfrost/panfrost_gem.h
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/panfrost/panfrost_gem.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/panfrost/panfrost_gem.h- Extension
.h- Size
- 4925 bytes
- Lines
- 171
- 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_shmem_helper.hdrm/drm_mm.h
Detected Declarations
struct panfrost_mmustruct panfrost_devicestruct panfrost_gem_debugfsstruct panfrost_gem_objectstruct panfrost_gem_mappingenum panfrost_debugfs_gem_state_flagsfunction drm_mm_node_to_panfrost_mapping
Annotated Snippet
struct panfrost_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;
};
struct panfrost_gem_object {
struct drm_gem_shmem_object base;
struct sg_table *sgts;
/*
* Use a list for now. If searching a mapping ever becomes the
* bottleneck, we should consider using an RB-tree, or even better,
* let the core store drm_gem_object_mapping entries (where we
* could place driver specific data) instead of drm_gem_object ones
* in its drm_file->object_idr table.
*
* struct drm_gem_object_mapping {
* struct drm_gem_object *obj;
* void *driver_priv;
* };
*/
struct {
struct list_head list;
struct mutex lock;
} mappings;
/*
* Count the number of jobs referencing this BO so we don't let the
* shrinker reclaim this object prematurely.
*/
atomic_t gpu_usecount;
/*
* Object chunk size currently mapped onto physical memory
*/
size_t heap_rss_size;
/**
* @label: BO tagging fields. The label can be assigned within the
* driver itself or through a specific IOCTL.
*/
struct {
/**
* @label.str: Pointer to NULL-terminated string,
*/
const char *str;
/** @lock.str: Protects access to the @label.str field. */
struct mutex lock;
} label;
bool noexec :1;
bool is_heap :1;
/* On coherent devices, this reflects the creation flags, not the true
* cacheability attribute of the mapping.
*/
bool wb_mmap :1;
#ifdef CONFIG_DEBUG_FS
struct panfrost_gem_debugfs debugfs;
#endif
};
struct panfrost_gem_mapping {
struct list_head node;
struct kref refcount;
struct panfrost_gem_object *obj;
struct drm_mm_node mmnode;
struct panfrost_mmu *mmu;
bool active :1;
};
static inline
struct panfrost_gem_object *to_panfrost_bo(struct drm_gem_object *obj)
{
return container_of(to_drm_gem_shmem_obj(obj), struct panfrost_gem_object, base);
}
Annotation
- Immediate include surface: `drm/drm_gem_shmem_helper.h`, `drm/drm_mm.h`.
- Detected declarations: `struct panfrost_mmu`, `struct panfrost_device`, `struct panfrost_gem_debugfs`, `struct panfrost_gem_object`, `struct panfrost_gem_mapping`, `enum panfrost_debugfs_gem_state_flags`, `function drm_mm_node_to_panfrost_mapping`.
- 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.