smu_dpm_set_power_gate(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– smu_dpm_set_power_gate(9) πŸ’–

okay so welcome to smu_dpm_set_power_gate(9), straight outta the Kernel API Manual β€” this is your girl's guide to gating and ungating a specific IP block, and yes we're gonna slay it ✨


🌸 NAME 🌸

smu_dpm_set_power_gate β€” power gate/ungate the specific IP block πŸ‘‘


πŸ¦‹ SYNOPSIS πŸ¦‹

int smu_dpm_set_power_gate (void *handle , uint32_t block_type , bool
gate , int inst );

πŸŽ€ ARGUMENTS πŸŽ€

  • handle β€” the smu_context pointer, iconic, the main character of this whole function ngl 🫢
  • block_type β€” which IP block we're power gating/ungating, iykyk
  • gate β€” if it's true we power gate it, otherwise we ungate it. literally that simple πŸ’…
  • inst β€” which instance of the IP block we're power gating/ungating, like which copy bestie 🌈

✨ DESCRIPTION ✨

so this API uses no smu->mutex lock protection, and before you come for her, here's exactly why:

  1. It's either called by another IP block (gfx/sdma/vcn/uvd/vce) β€” and that call is guarded to be race condition free by the caller. so the caller's got her back, no cap πŸ’œ
  2. Or it gets called on a user setting request of power_dpm_force_performance_level. In that case, the smu->mutex lock protection is already enforced on the parent API smu_force_performance_level of the call path. so like, it's handled upstream, we're good πŸ”₯
fr fr though, don't go thinking you should add your own locking casually β€” this page is telling you why she doesn't need it in these two cases 😭

🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c


and that's the whole page bestie, you ate that πŸ“

signing off from ./drivers/gpu/drm/amd/pm/swsmu β€” that's the source, the version is the Kernel API Manual, and this cutie's dated October 2026 πŸ’…βœ¨ see you in the next manpage mwah πŸ˜­πŸ’–

πŸ“¦ where this page comes from