STRUCT SCMI_POWERCAP_PROTO_OPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

struct scmi_powercap_proto_ops β€” okay bestie, this is the struct that holds all the operations the SCMI Powercap Protocol hands you 🫢 it's literally the vibe check for everything you can do to a powercap domain.

This is from the Kernel API Manual, and we're about to go through it together, no cap.


✨ SYNOPSIS ✨

struct scmi_powercap_proto_ops {
    int (*num_domains_get)(const struct scmi_protocol_handle *ph);
    const struct scmi_powercap_info __must_check *(*info_get) (const struct scmi_protocol_handle *ph, u32 domain_id);
    int (*cap_get)(const struct scmi_protocol_handle *ph, u32 domain_id, u32 *power_cap);
    int (*cap_set)(const struct scmi_protocol_handle *ph, u32 domain_id, u32 power_cap, bool ignore_dresp);
    int (*cap_enable_set)(const struct scmi_protocol_handle *ph, u32 domain_id, bool enable);
    int (*cap_enable_get)(const struct scmi_protocol_handle *ph, u32 domain_id, bool *enable);
    int (*pai_get)(const struct scmi_protocol_handle *ph, u32 domain_id, u32 *pai);
    int (*pai_set)(const struct scmi_protocol_handle *ph, u32 domain_id, u32 pai);
    int (*measurements_get)(const struct scmi_protocol_handle *ph, u32 domain_id, u32 *average_power, u32 *pai);
    int (*measurements_threshold_set)(const struct scmi_protocol_handle *ph, u32 domain_id, u32 power_thresh_low, u32 power_thresh_high);
    int (*measurements_threshold_get)(const struct scmi_protocol_handle *ph, u32 domain_id, u32 *power_thresh_low, u32 *power_thresh_high);
 };

look at all those function pointers, it's giving very much "organized chaos" and honestly? we love her πŸ’…


πŸŽ€ Members πŸŽ€

  • num_domains_get β€” get the count of powercap domains provided by SCMI. literally just "how many we got" energy ✨
  • info_get β€” get the information for the specified domain. and bestie, it's marked __must_check for a reason β€” you WILL check that return value, no skipping πŸ™ˆ
  • cap_get β€” get the current CAP value for the specified domain. on SCMI platforms that support powercap zone disabling, this could report a zero value for a zone where powercapping is disabled. so like, a zero here isn't automatically a glitch, it's context-dependent, iykyk πŸ‘‘
  • cap_set β€” set the CAP value for the specified domain to the provided value; if the domain supports setting the CAP with an asynchronous command, this request will finally trigger an asynchronous transfer, but if ignore_dresp here is set to true, this call will anyway return immediately without waiting for the related delayed response.
🚨 important one, bestie: the powercap requested value must NOT be zero, even if the platform supports disabling a powercap by setting its cap to zero (since SCMI v3.2) β€” there are dedicated operations that should be used for that. (cap_enable_set/cap_enable_get) πŸ’€
  • cap_enable_set β€” enable or disable the powercapping on the specified domain, if supported by the SCMI platform implementation.
heads up: by the SCMI specification, the platform can silently ignore our disable request and decide to enforce anyway some other powercap value requested by another agent on the system. for this reason cap_get and cap_enable_get will always report the final platform view of the powercaps. so don't @ us if the platform does its own thing, we're just reporting it πŸ¦‹
  • cap_enable_get β€” get the current CAP enable status for the specified domain. cute little true/false moment 🌸
  • pai_get β€” get the current PAI value for the specified domain.
  • pai_set β€” set the PAI value for the specified domain to the provided value. slay, symmetric πŸ’…
  • measurements_get β€” retrieve the current average power measurements for the specified domain and the related PAI upon which is calculated. the math is mathing πŸ”₯
  • measurements_threshold_set β€” set the desired low and high power thresholds to be used when registering for notification of type POWERCAP_MEASUREMENTS_NOTIFY with this powercap domain.
⭐ this one has rules: it must be called at least once before registering any callback with the usual scmi_notify_ops. moreover, in case this method is called with measurement notifications already enabled, it will also trigger, transparently, a proper update of the power thresholds configured in the SCMI backend server. iconic, honestly 🧚
  • measurements_threshold_get β€” get the currently configured low and high power thresholds used when registering callbacks for notification POWERCAP_MEASUREMENTS_NOTIFY. matching set, we stan a pair 🌈

πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file ./include/linux/scmi_protocol.h β€” go read it, it's the main character of this whole situation fr fr πŸ’œ

  • struct scmi_base_info(9)
  • struct scmi_clk_proto_ops(9)
  • struct scmi_perf_proto_ops(9)
  • struct scmi_power_proto_ops(9)
  • struct scmi_sensor_reading(9)
  • struct scmi_range_attrs(9)
  • struct scmi_sensor_axis_info(9)
  • struct scmi_sensor_intervals_info(9)
  • struct scmi_sensor_info(9)
  • struct scmi_sensor_proto_ops(9)
  • struct scmi_reset_proto_ops(9)
  • struct scmi_voltage_info(9)
  • struct scmi_voltage_proto_ops(9)
  • struct scmi_powercap_info(9)
  • struct scmi_pinctrl_proto_ops(9)
  • struct scmi_notify_ops(9)
  • struct scmi_handle(9)
  • module_scmi_driver(9)
  • module_scmi_protocol(9)

and that's the whole page, bestie 🫢 this one comes from ./include/linux, dated October 2026 β€” go forth and powercap responsibly, mwah πŸ’–πŸ’…

πŸ“¦ where this page comes from