STRUCT TPMI_PER_POWER_DOMAIN_INFO(9)

okay so welcome to the Kernel API Manual, bestie — we're doing a full deep-dive on struct tpmi_per_power_domain_info and honestly it's a lot but we're gonna slay it together 💅✨

✨ NAME ✨

struct tpmi_per_power_domain_info — the lil container that stores per power_domain SST info 🎀

---

🦋 SYNOPSIS 🦋

okay so here's the whole struct laid out, character for character, no cap:

struct tpmi_per_power_domain_info {
    int package_id;
    int power_domain_id;
    int max_level;
    int ratio_unit;
    int avx_levels;
    int pp_block_size;
    struct sst_header sst_header;
    struct cp_header cp_header;
    struct pp_header pp_header;
    struct perf_level *perf_levels;
    struct feature_offset feature_offsets;
    struct pp_control_offset control_offset;
    struct pp_status_offset status_offset;
    void __iomem *sst_base;
    struct auxiliary_device *auxdev;
    u64 saved_sst_cp_control;
    u64 saved_clos_configs[4];
    u64 saved_clos_assocs[4];
    u64 saved_pp_control;
    bool write_blocked;
 };

---

🌸 Members 🌸

okay here's the member-by-member breakdown, bestie, every single one 🫶

• package_id — the package id for this here power_domain 👑
• power_domain_id — the power domain id. Real talk: each and every entry that comes off the SST-TPMI instance is a power_domain, iykyk.
• max_level — the max possible PP level this power_domain can hit 🔥
• ratio_unit — the ratio unit, which is how you convert stuff over to MHz 🌈
• avx_levels — the number of AVX levels, periodt
• pp_block_size — the block size that comes from the PP header 🎀
• sst_header — keeps the SST header for this power_domain stored away safely
• cp_header — keeps the SST-CP header for this power_domain
• pp_header — keeps the SST-PP header for this power_domain
• perf_levels — pointer to each perf level, so you can map a level over to its mmio offset ⭐
• feature_offsets — stores the feature offsets for each PP-level
• control_offset — stores the control offset for each PP-level
• status_offset — stores the status offset for each PP-level
• sst_base — the mapped SST base IO memory 💜
• auxdev — the auxiliary device instance that enumerated this instance
• saved_sst_cp_control — saves the SST-CP control configuration so it can be stored + restored across suspend/resume 😴
• saved_clos_configs — saves the SST-CP CLOS configuration so it can be stored + restored across suspend/resume
• saved_clos_assocs — saves the SST-CP CLOS association so it can be stored + restored across suspend/resume
• saved_pp_control — saves the SST-PP control information so it can be stored + restored across suspend/resume
• write_blocked — write operation is blocked, so bestie literally cannot change the SST state, don't even try 💀

---

💖 Description 💖

so this structure is the one that stores the complete SST information for a power_domain. that info is what gets used for read/write requests for any SST IOCTL — it's giving main character energy for the whole flow ✨

and listen: each physical CPU package can have multiple power_domains. every power domain describes its own SST information, and it has its own controls. no sharing, no borrowing, everyone's got their own vibe check 🧚

---

🌟 SEE ALSO 🌟

Kernel file ./drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c plus these absolute icons:

• struct sst_header(9)
• struct cp_header(9)
• struct pp_header(9)
• struct feature_offset(9)
• struct levels_offset(9)
• struct pp_control_offset(9)
• struct pp_status_offset(9)
• struct perf_level(9)
• struct tpmi_sst_struct(9)
• struct tpmi_sst_common_struct(9)
• map_cdies(9)
• map_partition_power_domain_id(9)

---

ngl bestie, if you got all the way down here you ate that. go read the SEE ALSOs and hydrate 💧

okay bye ily — this came from ./drivers/platform/x86/intel/s... and it's dated October 2026, and it's the struct tpmi..._domain_info(9) page signing off 🎀💅🦋