STRUCT IRIS_HFI_QUEUE_HEADER(9)

💖 NAME 💖

struct iris_hfi_queue_header — okay bestie, this is the struct that holds the header for an Iris HFI queue, and yeah, it's lowkey the vibe check for the whole queue 🎀

(this lives in the Kernel API Manual, in case you were wondering which manual we're living in today ✨)

---

🌸 SYNOPSIS 🌸

struct iris_hfi_queue_header {
    u32 status;
    u32 start_addr;
    u16 queue_type;
    u16 header_type;
    u32 q_size;
    u32 pkt_size;
    u32 pkt_drop_cnt;
    u32 rx_wm;
    u32 tx_wm;
    u32 rx_req;
    u32 tx_req;
    u32 rx_irq_status;
    u32 tx_irq_status;
    u32 read_idx;
    u32 write_idx;
 };

Like, look at her. Fifteen fields, all of them main character energy. No cap, every single one matters 👑

---

🦋 Members 🦋

• status — the queue status, and it's chillin' in bits (7:0): 0x1 means active, 0x0 means inactive. That's the whole mood board for this field 💅
• start_addr — where the queue starts in non cached memory. Not cached, bestie, don't forget that part 🙈
• queue_type — the Queue ID. It's giving name tag at a party 🎀
• header_type — Default queue header. The standard fit, no custom vibes ✨
• q_size — the queue size, and it's a two-for-one situation:
  • if pkt_size is non-zero → it's the number of queue packets
  • if pkt_size is zero → it's the queue size in bytes

literally the same field with two whole personalities 😭

• pkt_size — size of queue packet entries:
  • 0x0 → variable queue packet size
  • non zero → size of the queue packet entry, fixed

pick a lane, honestly 💀

• pkt_drop_cnt — number of packets dropped by the sender. Not the flex we wanted but okay 🫶
• rx_wm — Receiver watermark, applicable in event driven mode. Mark that water, queen 🌊
• tx_wm — Sender watermark, also applicable in event driven mode. Event driven mode girlies rise 🌈
• rx_req — the Receiver sets this bit if the queue is empty. Empty queue = receiver's little flag moment 🚩
• tx_req — the Sender sets this bit if the queue is full. Full queue, sender hits the flag too 🚩
• rx_irq_status — the Receiver sets this bit and triggers an interrupt to the sender after packets are dequeued. Then the Sender clears this bit. Yes bestie, setting and clearing are two different people, keep up 😤
• tx_irq_status — the Sender sets this bit and triggers an interrupt to the receiver after packets are queued. Then the Receiver clears this bit. Same deal, opposite direction, iconic symmetry 👑
• read_idx — index till where the receiver has consumed the packets from the queue. How far the receiver got, periodt 📖
• write_idx — index till where the sender has written the packets into the queue. How far the sender got, and yes they're absolutely in their own lane ✍️

---

⭐ SEE ALSO ⭐

• Kernel file ./drivers/media/platform/qcom/iris/iris_hfi_queue.h
• struct iris_hfi_queue_table_header(9) — the sequel, go read it next, iykyk 🧚

---

ngl the only teeny tiny detail I want you to hold onto: q_size and pkt_size are out here reading each other's vibes, and rx_irq_status / tx_irq_status are a matched set where one side sets and the other side clears. Don't mix 'em up or it's gonna be a whole thing 💀

---

okay that's the whole page bestie!! this slayed its way out of ./drivers/media/platform/qcom/..., October 2026 edition — that's the source/version and date right there, mwah, go forth and queue responsibly 💖✨🎀🦋