STRUCT PANTHOR_SYNC_SIGNAL(9)

🦋 struct panthor_sync_signal(9) 🦋

okay so this is the Kernel API Manual page for struct panthor_sync_signal, and bestie we are about to get into the sync-object lore. It’s giving “tiny struct, big job-submission energy” and I’m obsessed. 💅

💖 NAME 💖

struct panthor_sync_signal — this struct represents a synchronization object point, aka the spot to attach our job fence to. Slay.

✨ SYNOPSIS ✨

struct panthor_sync_signal {
    struct list_head node;
    u32 handle;
    u64 point;
    struct drm_syncobj *syncobj;
    struct dma_fence_chain *chain;
    struct dma_fence *fence;
};

🎀 Members 🎀

• node — a list_head to track signal ops within a submit operation. Think of it as the list that keeps the signal-op girlies together during one submit operation.
• handle — the syncobj handle. That’s the handle ID situation.
• point — the syncobj point. Zero for regular syncobjs, and non-zero for timeline syncobjs. Not me remembering both cases? We love a clear distinction. 💅
• syncobj — the sync object pointed by handle. Yes, the actual sync object that handle is pointing at.
• chain — chain object used to link the new fence to an existing timeline syncobj. NULL for regular syncobj, non-NULL for timeline syncobjs. The timeline syncobj girlies get the non-NULL treatment.
• fence — the fence to assign to the syncobj or syncobj-point. The main character fence, basically.

🦋 Description 🦋

okay so this structure is here to keep track of fences that are currently bound to a specific syncobj point. That’s the whole vibe: it’s the bookkeeping baddie for fence-to-point situations.

At the beginning of a job submission, the fence is retrieved from the syncobj itself, and it can be NULL if no fence was attached to this point. No fence? No problem — NULL is valid here.

At the end, it points to the fence of the last job that had a DRM_PANTHOR_SYNC_OP_SIGNAL on this syncobj. So it follows the handoff through the process.

With jobs being submitted in batches, the fence might change several times during the process, allowing one job to wait on a job that’s part of the same submission but appears earlier in the drm_panthor_group_submit::queue_submits array. The way that works is lowkey iconic: earlier-in-the-array job, meet later job’s wait. 🫶

🌈 SEE ALSO 🌈

• Kernel file ./drivers/gpu/drm/panthor/panthor_drv.c user <-> kernel object copy helpers.(9)
• panthor_set_uobj(9)
• panthor_get_uobj_array(9)
• PANTHOR_UOBJ_MIN_SIZE_INTERNAL(9)
• PANTHOR_UOBJ_DECL(9)
• PANTHOR_UOBJ_MIN_SIZE(9)
• PANTHOR_UOBJ_SET(9)
• PANTHOR_UOBJ_GET_ARRAY(9)
• struct panthor_job_ctx(9)
• struct panthor_submit_ctx(9)
• panthor_check_sync_op(9)
• panthor_sync_signal_free(9)
• panthor_submit_ctx_add_sync_signal(9)
• panthor_submit_ctx_search_sync_signal(9)
• panthor_submit_ctx_add_job(9)
• panthor_submit_ctx_get_sync_signal(9)
• panthor_submit_ctx_update_job_sync_signal_fences(9)
• panthor_submit_ctx_collect_job_signal_ops(9)
• panthor_submit_ctx_push_fences(9)
• panthor_submit_ctx_add_sync_deps_to_job(9)
• panthor_submit_ctx_collect_jobs_signal_ops(9)
• panthor_submit_ctx_add_deps_and_arm_jobs(9)
• panthor_submit_ctx_push_jobs(9)
• panthor_submit_ctx_init(9)
• panthor_submit_ctx_cleanup(9)

kisses bestie 🫶💖 — source/version: ./drivers/gpu/drm/panthor; date: October 2026; page: struct panthor_sync_signal(9). byeee, go attach those fences responsibly. 💅✨