drivers/gpu/drm/omapdrm/omap_gem.c
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/omapdrm/omap_gem.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/omapdrm/omap_gem.c- Extension
.c- Size
- 39381 bytes
- Lines
- 1524
- 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.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/dma-mapping.hlinux/seq_file.hlinux/shmem_fs.hlinux/spinlock.hlinux/vmalloc.hdrm/drm_dumb_buffers.hdrm/drm_prime.hdrm/drm_print.hdrm/drm_vma_manager.homap_drv.homap_dmm_tiler.h
Detected Declarations
struct omap_gem_objectstruct omap_drm_usergart_entrystruct omap_drm_usergartfunction omap_gem_mmap_offsetfunction omap_gem_sgt_is_contiguousfunction omap_gem_is_contiguousfunction omap_gem_evict_entryfunction omap_gem_evictfunction omap_gem_attach_pagesfunction omap_gem_detach_pagesfunction omap_gem_flagsfunction omap_gem_mmap_sizefunction omap_gem_fault_1dfunction omap_gem_fault_2dfunction omap_gem_faultfunction omap_gem_object_mmapfunction omap_gem_dumb_createfunction omap_gem_dumb_map_offsetfunction omap_gem_rollfunction omap_gem_is_cached_coherentfunction omap_gem_cpu_sync_pagefunction omap_gem_dma_sync_bufferfunction omap_gem_pin_tilerfunction omap_gem_pinfunction omap_gem_unpin_lockedfunction omap_gem_unpinfunction omap_gem_rotated_dma_addrfunction omap_gem_tiled_stridefunction countfunction omap_gem_put_pagesfunction for_each_sgfunction omap_gem_put_sgfunction omap_gem_resumefunction omap_gem_describefunction omap_gem_describe_objectsfunction list_for_each_entryfunction omap_gem_free_objectfunction omap_gem_validate_flagsfunction omap_gem_new_handlefunction omap_gem_initfunction omap_gem_deinit
Annotated Snippet
struct omap_gem_object {
struct drm_gem_object base;
struct list_head mm_list;
u32 flags;
/** width/height for tiled formats (rounded up to slot boundaries) */
u16 width, height;
/** roll applied when mapping to DMM */
u32 roll;
/** protects pin_cnt, block, pages, dma_addrs and vaddr */
struct mutex lock;
/**
* dma_addr contains the buffer DMA address. It is valid for
*
* - buffers allocated through the DMA mapping API (with the
* OMAP_BO_MEM_DMA_API flag set)
*
* - buffers imported from dmabuf (with the OMAP_BO_MEM_DMABUF flag set)
* if they are physically contiguous
*
* - buffers mapped through the TILER when pin_cnt is not zero, in which
* case the DMA address points to the TILER aperture
*
* Physically contiguous buffers have their DMA address equal to the
* physical address as we don't remap those buffers through the TILER.
*
* Buffers mapped to the TILER have their DMA address pointing to the
* TILER aperture. As TILER mappings are refcounted (through pin_cnt)
* the DMA address must be accessed through omap_gem_pin() to ensure
* that the mapping won't disappear unexpectedly. References must be
* released with omap_gem_unpin().
*/
dma_addr_t dma_addr;
/**
* # of users
*/
refcount_t pin_cnt;
/**
* If the buffer has been imported from a dmabuf the OMAP_DB_DMABUF flag
* is set and the sgt field is valid.
*/
struct sg_table *sgt;
/**
* tiler block used when buffer is remapped in DMM/TILER.
*/
struct tiler_block *block;
/**
* Array of backing pages, if allocated. Note that pages are never
* allocated for buffers originally allocated from contiguous memory
*/
struct page **pages;
/** addresses corresponding to pages in above array */
dma_addr_t *dma_addrs;
/**
* Virtual address, if mapped.
*/
void *vaddr;
};
#define to_omap_bo(x) container_of(x, struct omap_gem_object, base)
/* To deal with userspace mmap'ings of 2d tiled buffers, which (a) are
* not necessarily pinned in TILER all the time, and (b) when they are
* they are not necessarily page aligned, we reserve one or more small
* regions in each of the 2d containers to use as a user-GART where we
* can create a second page-aligned mapping of parts of the buffer
* being accessed from userspace.
*
* Note that we could optimize slightly when we know that multiple
* tiler containers are backed by the same PAT.. but I'll leave that
* for later..
*/
#define NUM_USERGART_ENTRIES 2
struct omap_drm_usergart_entry {
struct tiler_block *block; /* the reserved tiler block */
dma_addr_t dma_addr;
struct drm_gem_object *obj; /* the current pinned obj */
pgoff_t obj_pgoff; /* page offset of obj currently
mapped in */
Annotation
- Immediate include surface: `linux/dma-mapping.h`, `linux/seq_file.h`, `linux/shmem_fs.h`, `linux/spinlock.h`, `linux/vmalloc.h`, `drm/drm_dumb_buffers.h`, `drm/drm_prime.h`, `drm/drm_print.h`.
- Detected declarations: `struct omap_gem_object`, `struct omap_drm_usergart_entry`, `struct omap_drm_usergart`, `function omap_gem_mmap_offset`, `function omap_gem_sgt_is_contiguous`, `function omap_gem_is_contiguous`, `function omap_gem_evict_entry`, `function omap_gem_evict`, `function omap_gem_attach_pages`, `function omap_gem_detach_pages`.
- 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.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.