STRUCT OMAP_HWMOD(9)

💅 struct omap_hwmod — wait, what is it?? (NAME)

okay bestie so this is struct omap_hwmod, and it's literally the integration data for OMAP hardware "modules" (also known as IP blocks). that's it, that's the vibe. this page lives in the Kernel API Manual btw, so you know it's official ✨

---

🌸 SYNOPSIS 🌸

here's the whole struct, no cap, every field exactly as it is:

struct omap_hwmod {
    const char                      *name;
    struct omap_hwmod_class         *class;
    struct omap_device              *od;
    struct omap_hwmod_rst_info      *rst_lines;
    union {
      struct omap_hwmod_omap2_prcm omap2;
      struct omap_hwmod_omap4_prcm omap4;
    } prcm;
    const char                      *main_clk;
    struct clk                      *_clk;
    struct omap_hwmod_opt_clk       *opt_clks;
    const char                      *clkdm_name;
    struct clockdomain              *clkdm;
    struct list_head                slave_ports;
    void *dev_attr;
    u32 _sysc_cache;
    void __iomem                    *_mpu_rt_va;
    spinlock_t _lock;
    struct lock_class_key           hwmod_key;
    struct list_head                node;
    struct omap_hwmod_ocp_if        *_mpu_port;
    u32 flags;
    u8 mpu_rt_idx;
    u8 response_lat;
    u8 rst_lines_cnt;
    u8 opt_clks_cnt;
    u8 slaves_cnt;
    u8 hwmods_cnt;
    u8 _int_flags;
    u8 _state;
    u8 _postsetup_state;
    struct omap_hwmod               *parent_hwmod;
 };

---

🎀 Members 🎀

okay so here's the member-by-member breakdown, and yes i'm doing all of them, we're not skipping 💖

• name — the name of the hwmod, that's her whole identity
• class — a struct omap_hwmod_class * pointing at the class of this hwmod 👑
• od — the struct omap_device currently associated with this hwmod (internal use, so hands off bestie)
• prcm — the PRCM data pertaining to this hwmod
• main_clk — main clock, i.e. the OMAP clock name
• _clk — pointer to the main struct clk (this one gets filled in at runtime, sneaky)
• opt_clks — other device clocks that drivers can request, range is 0..* so like, as many as you want
• dev_attr — arbitrary device attributes that can be passed to the driver, very "here's some extra stuff" energy
• _sysc_cache — internal-use hwmod flags
• _mpu_rt_va — cached register target start address (internal use)
• _lock — a spinlock that serializes operations on this hwmod, one at a time babes 🔒
• node — list node for the hwmod list (internal use)
• _mpu_port — cached MPU register target slave (internal use)
• flags — hwmod flags (these are documented below, btw)
• mpu_rt_idx — index of the device address space for the register target (for DT boot)
• response_lat — device OCP response latency, measured in interface clock cycles ⏱️
• opt_clks_cnt — number of opt_clks
• slaves_cnt — number of slave entries
• _int_flags — internal-use hwmod flags
• _state — internal-use hwmod state
• _postsetup_state — internal-use state to leave the hwmod in after _setup
• parent_hwmod — (temporary!) a pointer to the hierarchical parent of this hwmod

🙈 quick heads up: this list isn't the whole struct, it's the members the page spells out. the SYNOPSIS above is the full field list, so go look there if you need the rest, i'm not out here inventing lore.

---

✨ Description ✨

okay so main_clk refers to this module's "main clock," and for our purposes that's defined as "the functional clock needed for register accesses to complete." that's the whole definition, it's giving very precise. and listen — modules may not have a main clock at all, if the interface clock also serves as a main clock. so don't come for me if it's missing, it's allowed 💅

Parameter names beginning with an underscore are managed internally by the omap_hwmod code, and bestie, you should not set them during initialization. that's an internal thing, stay out of it, fr fr 🙏

masters and slaves are now deprecated. yes, both of them, deprecated. moving on 🌈

parent_hwmod is temporary — there should be no need for it, because this information should already be expressed in the OCP interface structures. it's only present as a workaround until we improve handling for hwmods with multiple parents (e.g., OMAP4+ DSS with multiple register targets across different interconnects). so like, it's a temporary situation, it's giving "this is fine for now" 😭

---

🔥 SEE ALSO 🔥

Kernel file ./arch/arm/mach-omap2/omap_hwmod.h struct, plus all of these besties:

• omap_hwmod_rst_info(9)
• struct omap_hwmod_opt_clk(9)
• struct omap_hwmod_omap2_firewall(9)
• struct omap_hwmod_ocp_if(9)
• struct omap_hwmod_class_sysconfig(9)
• struct omap_hwmod_omap2_prcm(9)
• struct omap_hwmod_omap4_prcm(9)
• struct omap_hwmod_class(9)

---

okay that's the whole page, you ate that 🫶 this one comes to you from ./arch/arm/mach-omap2, dated October 2026, and the page itself is struct omap_hwmod(9) — mwah, go read some hwmod structs, ily, bye 💜