drivers/gpu/drm/armada/armada_gem.c
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/armada/armada_gem.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/armada/armada_gem.c- Extension
.c- Size
- 13459 bytes
- Lines
- 563
- 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.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
- 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-buf.hlinux/dma-mapping.hlinux/mman.hlinux/shmem_fs.hdrm/armada_drm.hdrm/drm_prime.hdrm/drm_print.harmada_drm.harmada_gem.harmada_ioctlP.h
Detected Declarations
function armada_gem_vm_faultfunction roundup_gem_sizefunction armada_gem_free_objectfunction armada_gem_linear_backfunction allocationfunction dma_alloc_coherentfunction armada_gem_map_objectfunction armada_gem_alloc_private_objectfunction armada_gem_dumb_createfunction armada_gem_create_ioctlfunction armada_gem_mmap_ioctlfunction armada_gem_pwrite_ioctlfunction armada_gem_prime_map_dma_buffunction for_each_sgtable_sgfunction armada_gem_prime_unmap_dma_buffunction armada_gem_dmabuf_mmapfunction armada_gem_prime_exportfunction armada_gem_prime_importfunction armada_gem_map_import
Annotated Snippet
if (p) {
obj->addr = page_address(p);
obj->phys_addr = page_to_phys(p);
obj->page = p;
memset(obj->addr, 0, PAGE_ALIGN(size));
}
}
/*
* We could grab something from DMA if it's enabled, but that
* involves building in a problem:
*
* GEM DMA helper interface uses dma_alloc_coherent(), which provides
* us with an CPU virtual address and a device address.
*
* The CPU virtual address may be either an address in the kernel
* direct mapped region (for example, as it would be on x86) or
* it may be remapped into another part of kernel memory space
* (eg, as it would be on ARM.) This means virt_to_phys() on the
* returned virtual address is invalid depending on the architecture
* implementation.
*
* The device address may also not be a physical address; it may
* be that there is some kind of remapping between the device and
* system RAM, which makes the use of the device address also
* unsafe to re-use as a physical address.
*
* This makes DRM usage of dma_alloc_coherent() in a generic way
* at best very questionable and unsafe.
*/
/* Otherwise, grab it from our linear allocation */
if (!obj->page) {
struct drm_mm_node *node;
unsigned align = min_t(unsigned, size, SZ_2M);
void __iomem *ptr;
int ret;
node = kzalloc_obj(*node);
if (!node)
return -ENOSPC;
mutex_lock(&priv->linear_lock);
ret = drm_mm_insert_node_generic(&priv->linear, node,
size, align, 0, 0);
mutex_unlock(&priv->linear_lock);
if (ret) {
kfree(node);
return ret;
}
obj->linear = node;
/* Ensure that the memory we're returning is cleared. */
ptr = ioremap_wc(obj->linear->start, size);
if (!ptr) {
mutex_lock(&priv->linear_lock);
drm_mm_remove_node(obj->linear);
mutex_unlock(&priv->linear_lock);
kfree(obj->linear);
obj->linear = NULL;
return -ENOMEM;
}
memset_io(ptr, 0, size);
iounmap(ptr);
obj->phys_addr = obj->linear->start;
obj->dev_addr = obj->linear->start;
obj->mapped = true;
}
DRM_DEBUG_DRIVER("obj %p phys %#llx dev %#llx\n", obj,
(unsigned long long)obj->phys_addr,
(unsigned long long)obj->dev_addr);
return 0;
}
void *
armada_gem_map_object(struct drm_device *dev, struct armada_gem_object *dobj)
{
/* only linear objects need to be ioremap'd */
if (!dobj->addr && dobj->linear)
dobj->addr = ioremap_wc(dobj->phys_addr, dobj->obj.size);
return dobj->addr;
}
static const struct drm_gem_object_funcs armada_gem_object_funcs = {
Annotation
- Immediate include surface: `linux/dma-buf.h`, `linux/dma-mapping.h`, `linux/mman.h`, `linux/shmem_fs.h`, `drm/armada_drm.h`, `drm/drm_prime.h`, `drm/drm_print.h`, `armada_drm.h`.
- Detected declarations: `function armada_gem_vm_fault`, `function roundup_gem_size`, `function armada_gem_free_object`, `function armada_gem_linear_back`, `function allocation`, `function dma_alloc_coherent`, `function armada_gem_map_object`, `function armada_gem_alloc_private_object`, `function armada_gem_dumb_create`, `function armada_gem_create_ioctl`.
- Atlas domain: Driver Families / drivers/gpu.
- Implementation status: source implementation candidate.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
- 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.