qman_init_fq(9)

👑 qman_init_fq(9) — like, the Kernel API Manual one 💅

okay bestie so this is a page straight out of the Kernel API Manual, and it's all about one tiny little function with main character energy: qman_init_fq. it sets up FQ fields and leaves the FQ either "parked" or "scheduled". that's the whole vibe. let's get into it 🎀

---

✨ NAME ✨

qman_init_fq — initialises FQ fields, and leaves the FQ "parked" or "scheduled". no cap, that's it. 🦋

---

🌸 SYNOPSIS 🌸

int qman_init_fq (struct qman_fq *fq , u32 flags , struct qm_mcc_initfq
*opts );

literally copy-paste that signature into your brain, bestie. it's giving three args, one int back. 🫶

---

💖 ARGUMENTS 💖

• fq — the frame queue object you're modifying, and it must be 'parked' or brand new. no exceptions, periodt. 🙈
• flags — a bit-mask of QMAN_INITFQ_FLAG_*** options. mix and match, it's a bit-mask, that's the whole point ✨
• opts — the FQ-modification settings, exactly as defined in the low-level API. yep, it's the low-level one. 🌈

---

🔥 DESCRIPTION 🔥

so the opts parameter comes from the low-level portal API. if you select QMAN_INITFQ_FLAG_SCHED in flags, the frame queue gets scheduled instead of parked. that's the flex. 💅

NB — opts can be NULL. yes bestie, NULL is fine here, no jump scare 😭

also heads up: some fields and options within opts may legitimately be ignored or overwritten by the driver. not a bug, that's just how it is. 💀 here's the whole breakdown:

1. the 'count' and 'fqid' fields are always ignored — because this operation only affects one frame queue: fq. one FQ, one job, focused queen energy 👑
2. the QM_INITFQ_WE_CONTEXTB option of the 'we_mask' field and the associated
   • if fq was not created with QMAN_FQ_FLAG_TO_DCPORTAL, then context_b is initialised to a value used by the driver for demux. 🧚
   • if context_b is initialised for demux, so is context_a in case stashing is requested (see item 4). (So caller control of context_b is only possible for TO_DCPORTAL frame queue objects.) ⭐
3. if flags contains QMAN_INITFQ_FLAG_LOCAL, the 'fqd' structure's the command. If the WE_DESTWQ write-enable bit had already been set by the caller, the channel workqueue will be left as-is, otherwise the write-enable bit is set and the workqueue is set to a default of 4. If the "LOCAL" flag isn't set, the destination channel/workqueue fields and the write-enable bit are left as-is. 🍓

(yeah, that item 3 sentence does just go off a cliff in the original — I'm not about to invent lore that isn't there, bestie 🙈)

4. if the driver overwrites context_a/context_b for demux, then if QM_INITFQ_WE_CONTEXTA is set, the driver will only overwrite context_a.address fields and will leave the stashing fields provided by the user alone, otherwise it will zero out the context_a.stashing fields. 🎀

---

💜 SEE ALSO 💜

the kernel file ./include/soc/fsl/qman.h and literally this whole friend group:

• qman_p_irqsource_add(9)
• qman_p_irqsource_remove(9)
• qman_affine_cpus(9)
• qman_affine_channel(9)
• qman_get_affine_portal(9)
• qman_start_using_portal(9)
• qman_p_poll_dqrr(9)
• qman_p_static_dequeue_add(9)
• qman_create_fq(9)
• qman_destroy_fq(9)
• qman_fq_fqid(9)
• qman_schedule_fq(9)
• qman_retire_fq(9)
• qman_oos_fq(9)
• qman_enqueue(9)
• qman_alloc_fqid_range(9)
• qman_release_fqid(9)
• qman_query_fq_np(9)
• qman_alloc_pool_range(9)
• qman_release_pool(9)
• qman_create_cgr(9)
• qman_delete_cgr(9)
• qman_delete_cgr_safe(9)
• qman_update_cgr_safe(9)
• qman_query_cgr_congested(9)
• qman_alloc_cgrid_range(9)
• qman_release_cgrid(9)
• qman_is_probed(9)
• qman_portals_probed(9)
• qman_dqrr_get_ithresh(9)
• qman_dqrr_set_ithresh(9)

---

and that's the page, bestie 🫶💖 this one lives under ./include/soc/fsl, and the date stamp on it is October 2026 — so yeah, it's already iconic in the future timeline 👑✨ go init those frame queues, ilysm 💅