drivers/gpu/drm/i915/gem/i915_gem_clflush.c
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/i915/gem/i915_gem_clflush.c- Extension
.c- Size
- 3649 bytes
- Lines
- 138
- 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.
- 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
drm/drm_cache.hi915_config.hi915_drv.hi915_gem_clflush.hi915_gem_object_frontbuffer.hi915_sw_fence_work.hi915_trace.h
Detected Declarations
struct clflushfunction __do_clflushfunction clflush_workfunction clflush_releasefunction i915_gem_clflush_object
Annotated Snippet
struct clflush {
struct dma_fence_work base;
struct drm_i915_gem_object *obj;
};
static void __do_clflush(struct drm_i915_gem_object *obj)
{
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
drm_clflush_sg(obj->mm.pages);
i915_gem_object_frontbuffer_flush(obj, ORIGIN_CPU);
}
static void clflush_work(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
__do_clflush(clflush->obj);
}
static void clflush_release(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
i915_gem_object_unpin_pages(clflush->obj);
i915_gem_object_put(clflush->obj);
}
static const struct dma_fence_work_ops clflush_ops = {
.name = "clflush",
.work = clflush_work,
.release = clflush_release,
};
static struct clflush *clflush_work_create(struct drm_i915_gem_object *obj)
{
struct clflush *clflush;
GEM_BUG_ON(!obj->cache_dirty);
clflush = kmalloc_obj(*clflush);
if (!clflush)
return NULL;
if (__i915_gem_object_get_pages(obj) < 0) {
kfree(clflush);
return NULL;
}
dma_fence_work_init(&clflush->base, &clflush_ops);
clflush->obj = i915_gem_object_get(obj); /* obj <-> clflush cycle */
return clflush;
}
bool i915_gem_clflush_object(struct drm_i915_gem_object *obj,
unsigned int flags)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct clflush *clflush;
assert_object_held(obj);
if (IS_DGFX(i915)) {
WARN_ON_ONCE(obj->cache_dirty);
return false;
}
/*
* Stolen memory is always coherent with the GPU as it is explicitly
* marked as wc by the system, or the system is cache-coherent.
* Similarly, we only access struct pages through the CPU cache, so
* anything not backed by physical memory we consider to be always
* coherent and not need clflushing.
*/
if (!i915_gem_object_has_struct_page(obj)) {
obj->cache_dirty = false;
return false;
}
/* If the GPU is snooping the contents of the CPU cache,
* we do not need to manually clear the CPU cache lines. However,
* the caches are only snooped when the render cache is
* flushed/invalidated. As we always have to emit invalidations
* and flushes when moving into and out of the RENDER domain, correct
* snooping behaviour occurs naturally as the result of our domain
* tracking.
*/
if (!(flags & I915_CLFLUSH_FORCE) &&
obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ)
Annotation
- Immediate include surface: `drm/drm_cache.h`, `i915_config.h`, `i915_drv.h`, `i915_gem_clflush.h`, `i915_gem_object_frontbuffer.h`, `i915_sw_fence_work.h`, `i915_trace.h`.
- Detected declarations: `struct clflush`, `function __do_clflush`, `function clflush_work`, `function clflush_release`, `function i915_gem_clflush_object`.
- Atlas domain: Driver Families / drivers/gpu.
- Implementation status: source implementation candidate.
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.