omap_iommu_d...n_deactivate(9)

🦋 omap_iommu_d...n_deactivate(9) 🦋

okay so this is a page straight out of the Kernel API Manual, and bestie, it's a short one but it's a good one. buckle up 💅

---

✨ NAME ✨

omap_iommu_domain_deactivate — deactivate attached iommu devices. that's it, that's the whole vibe 🎀

---

🌸 SYNOPSIS 🌸

int omap_iommu_domain_deactivate (struct iommu_domain *domain );

literally one argument, one return, no drama 🔥

---

💖 ARGUMENTS 💖

• domain — the iommu domain attached to the target iommu device. this is the friend group you're putting to sleep 😴

---

🧚 DESCRIPTION 🧚

okay so picture this: this API is what lets the client devices of IOMMU devices suspend the IOMMUs they control at runtime 🫶 and the rules are that they do it after they are idled and after they've suspended all activity. like, you can't just dip — you gotta be fully chill first, no cap.

and then the plot twist: System Suspend will leverage the PM driver late callbacks for this. 👑 so your system-wide nap is lowkey powered by the same mechanism, iconic.

---

🌈 SEE ALSO 🌈

• the Kernel file ./drivers/iommu/omap-iommu.c (yes, the source of truth, go read it iykyk) 📖
• to_omap_domain(9)
• omap_iommu_save_ctx(9)
• omap_iommu_restore_ctx(9)
• load_iotlb_entry(9)
• flush_iotlb_page(9)
• flush_iotlb_all(9)
• omap_iopgtable_store_entry(9)
• iopgtable_lookup_entry(9)
• iopgtable_clear_entry(9)
• omap_iommu_attach(9)
• omap_iommu_detach(9)
• omap_iommu_domain_activate(9)
• omap_iommu_runtime_suspend(9)
• omap_iommu_runtime_resume(9)
• omap_iommu_prepare(9)

like, the whole friend group is linked here — activate, deactivate, suspend, resume, attach, detach, save, restore… a full roster fr fr 💜

---

ngl the whole thing is basically "let the IOMMU take a nap, but only after everything's actually idle first." respect the order and you're golden ✨

---

and that's the page bestie!! this one came from ./drivers/iommu and it's dated October 2026 — mwah, sending you off with the whole squad of omap_iommu_* functions, slay 🍓💅👑