drivers/gpu/drm/i915/gem/i915_gem_busy.c
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/i915/gem/i915_gem_busy.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/i915/gem/i915_gem_busy.c- Extension
.c- Size
- 4501 bytes
- Lines
- 164
- 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
linux/dma-fence-array.hgt/intel_engine.hi915_gem_ioctls.hi915_gem_object.h
Detected Declarations
function __busy_read_flagfunction __busy_write_idfunction __busy_set_if_activefunction busy_check_readerfunction busy_check_writerfunction i915_gem_busy_ioctl
Annotated Snippet
// SPDX-License-Identifier: MIT
/*
* Copyright © 2014-2016 Intel Corporation
*/
#include <linux/dma-fence-array.h>
#include "gt/intel_engine.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
static __always_inline u32 __busy_read_flag(u16 id)
{
if (id == (u16)I915_ENGINE_CLASS_INVALID)
return 0xffff0000u;
GEM_BUG_ON(id >= 16);
return 0x10000u << id;
}
static __always_inline u32 __busy_write_id(u16 id)
{
/*
* The uABI guarantees an active writer is also amongst the read
* engines. This would be true if we accessed the activity tracking
* under the lock, but as we perform the lookup of the object and
* its activity locklessly we can not guarantee that the last_write
* being active implies that we have set the same engine flag from
* last_read - hence we always set both read and write busy for
* last_write.
*/
if (id == (u16)I915_ENGINE_CLASS_INVALID)
return 0xffffffffu;
return (id + 1) | __busy_read_flag(id);
}
static __always_inline unsigned int
__busy_set_if_active(struct dma_fence *fence, u32 (*flag)(u16 id))
{
const struct i915_request *rq;
/*
* We have to check the current hw status of the fence as the uABI
* guarantees forward progress. We could rely on the idle worker
* to eventually flush us, but to minimise latency just ask the
* hardware.
*
* Note we only report on the status of native fences and we currently
* have two native fences:
*
* 1. A composite fence (dma_fence_array) constructed of i915 requests
* created during a parallel submission. In this case we deconstruct the
* composite fence into individual i915 requests and check the status of
* each request.
*
* 2. A single i915 request.
*/
if (dma_fence_is_array(fence)) {
struct dma_fence_array *array = to_dma_fence_array(fence);
struct dma_fence **child = array->fences;
unsigned int nchild = array->num_fences;
do {
struct dma_fence *current_fence = *child++;
/* Not an i915 fence, can't be busy per above */
if (!dma_fence_is_i915(current_fence) ||
!test_bit(I915_FENCE_FLAG_COMPOSITE,
¤t_fence->flags)) {
return 0;
}
rq = to_request(current_fence);
if (!i915_request_completed(rq))
return flag(rq->engine->uabi_class);
} while (--nchild);
/* All requests in array complete, not busy */
return 0;
} else {
if (!dma_fence_is_i915(fence))
return 0;
rq = to_request(fence);
if (i915_request_completed(rq))
return 0;
/* Beware type-expansion follies! */
Annotation
- Immediate include surface: `linux/dma-fence-array.h`, `gt/intel_engine.h`, `i915_gem_ioctls.h`, `i915_gem_object.h`.
- Detected declarations: `function __busy_read_flag`, `function __busy_write_id`, `function __busy_set_if_active`, `function busy_check_reader`, `function busy_check_writer`, `function i915_gem_busy_ioctl`.
- 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.