dwc2_hcd_start_xfer_ddma(9)

💅 NAME 💅

dwc2_hcd_start_xfer_ddma — starts a transfer in Descriptor DMA mode ✨

Okay so real talk, this is a function from the Kernel API Manual, and it's lowkey the "get this transfer moving" moment for Descriptor DMA. Let's get into it 🫶

---

🌸 SYNOPSIS 🌸

void dwc2_hcd_start_xfer_ddma (struct dwc2_hsotg *hsotg , struct dwc2_qh
*qh );

Yes bestie it's void, and yes we'll talk about the RETURN section in a sec. Just… stay with me 😭

---

🎀 ARGUMENTS 🎀

• hsotg — the HCD state structure for the DWC OTG controller 💖 like, the whole controller's situation lives in here
• qh — the QH to init 👑 this is the one getting set up, main character energy fr

---

⭐ RETURN ⭐

0 if successful, negative error code otherwise.

That's what the page says, and that's what I'm telling you. Periodt 💅

---

🦋 DESCRIPTION 🦋

So here's the vibe check on what this actually does ✨

For Control and Bulk endpoints, it initializes the descriptor list and starts the transfer. Simple, clean, iconic 🌈

For Interrupt and Isochronous endpoints, it initializes the descriptor list and then updates FrameList, marking the appropriate entries as active. Very much a "set it up, then flag it live" sitch 💜

For Isochronous endpoints, the starting descriptor index is calculated based on the scheduled frame — but only on the first transfer descriptor within a session 🎯 Then the transfer is started via enabling the channel. Slay.

And also for Isochronous endpoints: the channel is not halted on the XferComplete interrupt, so it stays assigned to the endpoint (QH) until the session is done 🧚 Not me pointing out that this is the deliberate behaviour, okay, it's just how it works.

---

🔥 SEE ALSO 🔥

• Kernel file ./drivers/usb/dwc2/hcd_ddma.c — dwc2_hcd_qh_init_ddma(9), dwc2_hcd_qh_free_ddma(9), dwc2_hcd_complete_xfer_ddma(9) 🌟

---

And that's the whole page cutie 🍓 this came out of the ./drivers/usb/dwc2 corner of the kernel, dated October 2026 — go off, Descriptor DMA, no cap 💀✨