drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c- Extension
.c- Size
- 38526 bytes
- Lines
- 1400
- 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.
- 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/circ_buf.hlinux/ktime.hlinux/string_helpers.hlinux/time64.hlinux/timekeeping.hi915_drv.hi915_wait_util.hintel_guc_ct.hintel_guc_print.h
Detected Declarations
struct ct_requeststruct ct_incoming_msgfunction errorfunction intel_guc_ct_init_earlyfunction guc_ct_buffer_desc_initfunction guc_ct_buffer_resetfunction guc_ct_buffer_initfunction guc_action_control_ctbfunction ct_control_enablefunction ct_register_bufferfunction intel_guc_ct_initfunction intel_guc_ct_finifunction intel_guc_ct_enablefunction intel_guc_ct_disablefunction ct_track_lost_and_foundfunction ct_get_next_fencefunction ct_writefunction receivedfunction ct_deadlockedfunction g2h_has_roomfunction g2h_reserve_spacefunction g2h_release_spacefunction h2g_has_roomfunction has_room_nbfunction ct_send_nbfunction ct_sendfunction Transportfunction ct_free_msgfunction ct_readfunction ct_check_lost_and_foundfunction ct_check_lost_and_foundfunction ct_handle_responsefunction ct_process_requestfunction ct_process_incoming_requestsfunction ct_incoming_request_worker_funcfunction ct_handle_eventfunction ct_handle_hxgfunction ct_handle_msgfunction ct_receivefunction ct_try_receive_messagefunction ct_receive_tasklet_funcfunction intel_guc_ct_event_handlerfunction intel_guc_ct_print_infofunction ct_dead_ct_worker_func
Annotated Snippet
struct ct_request {
struct list_head link;
u32 fence;
u32 status;
u32 response_len;
u32 *response_buf;
};
struct ct_incoming_msg {
struct list_head link;
u32 size;
u32 msg[] __counted_by(size);
};
enum { CTB_SEND = 0, CTB_RECV = 1 };
enum { CTB_OWNER_HOST = 0 };
/*
* Some H2G commands involve a synchronous response that the driver needs
* to wait for. In such cases, a timeout is required to prevent the driver
* from waiting forever in the case of an error (either no error response
* is defined in the protocol or something has died and requires a reset).
* The specific command may be defined as having a time bound response but
* the CT is a queue and that time guarantee only starts from the point
* when the command reaches the head of the queue and is processed by GuC.
*
* Ideally there would be a helper to report the progress of a given
* command through the CT. However, that would require a significant
* amount of work in the CT layer. In the meantime, provide a reasonable
* estimation of the worst case latency it should take for the entire
* queue to drain. And therefore, how long a caller should wait before
* giving up on their request. The current estimate is based on empirical
* measurement of a test that fills the buffer with context creation and
* destruction requests as they seem to be the slowest operation.
*/
long intel_guc_ct_max_queue_time_jiffies(void)
{
/*
* A 4KB buffer full of context destroy commands takes a little
* over a second to process so bump that to 2s to be super safe.
*/
return (CTB_H2G_BUFFER_SIZE * HZ) / SZ_2K;
}
static void ct_receive_tasklet_func(struct tasklet_struct *t);
static void ct_incoming_request_worker_func(struct work_struct *w);
/**
* intel_guc_ct_init_early - Initialize CT state without requiring device access
* @ct: pointer to CT struct
*/
void intel_guc_ct_init_early(struct intel_guc_ct *ct)
{
spin_lock_init(&ct->ctbs.send.lock);
spin_lock_init(&ct->ctbs.recv.lock);
spin_lock_init(&ct->requests.lock);
INIT_LIST_HEAD(&ct->requests.pending);
INIT_LIST_HEAD(&ct->requests.incoming);
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
INIT_WORK(&ct->dead_ct_worker, ct_dead_ct_worker_func);
#endif
INIT_WORK(&ct->requests.worker, ct_incoming_request_worker_func);
tasklet_setup(&ct->receive_tasklet, ct_receive_tasklet_func);
init_waitqueue_head(&ct->wq);
}
static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
{
memset(desc, 0, sizeof(*desc));
}
static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
{
u32 space;
ctb->broken = false;
ctb->tail = 0;
ctb->head = 0;
space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size) - ctb->resv_space;
atomic_set(&ctb->space, space);
guc_ct_buffer_desc_init(ctb->desc);
}
static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
struct guc_ct_buffer_desc *desc,
u32 *cmds, u32 size_in_bytes, u32 resv_space)
{
GEM_BUG_ON(size_in_bytes % 4);
Annotation
- Immediate include surface: `linux/circ_buf.h`, `linux/ktime.h`, `linux/string_helpers.h`, `linux/time64.h`, `linux/timekeeping.h`, `i915_drv.h`, `i915_wait_util.h`, `intel_guc_ct.h`.
- Detected declarations: `struct ct_request`, `struct ct_incoming_msg`, `function error`, `function intel_guc_ct_init_early`, `function guc_ct_buffer_desc_init`, `function guc_ct_buffer_reset`, `function guc_ct_buffer_init`, `function guc_action_control_ctb`, `function ct_control_enable`, `function ct_register_buffer`.
- 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.