STRUCT SCMI_PERF_PROTO_OPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ struct scmi_perf_proto_ops(9) ✨

okay so this is a page from the Kernel API Manual, section 9, and it's literally the whole vibe of the SCMI Performance Protocol in one struct 🫢


πŸ’– NAME πŸ’–

struct scmi_perf_proto_ops β€” the struct that "represents the various operations provided by SCMI Performance Protocol". yes bestie, it's the whole ops menu, one struct, no notes πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

struct scmi_perf_proto_ops {
    int (*num_domains_get)(const struct scmi_protocol_handle *ph);
    const struct scmi_perf_domain_info __must_check *(*info_get) (const
struct scmi_protocol_handle *ph, u32 domain);
    int (*limits_set)(const struct scmi_protocol_handle *ph, u32 domain,
u32 max_perf, u32 min_perf);
    int (*limits_get)(const struct scmi_protocol_handle *ph, u32 domain,
u32 *max_perf, u32 *min_perf);
    int (*level_set)(const struct scmi_protocol_handle *ph, u32 domain,
u32 level, bool poll);
    int (*level_get)(const struct scmi_protocol_handle *ph, u32 domain,
u32 *level, bool poll);
    int (*transition_latency_get)(const struct scmi_protocol_handle *ph,
u32 domain);
    int (*rate_limit_get)(const struct scmi_protocol_handle *ph, u32
domain, u32 *rate_limit);
    int (*device_opps_add)(const struct scmi_protocol_handle *ph, struct
device *dev, u32 domain);
    int (*freq_set)(const struct scmi_protocol_handle *ph, u32 domain,
unsigned long rate, bool poll);
    int (*freq_get)(const struct scmi_protocol_handle *ph, u32 domain,
unsigned long *rate, bool poll);
    int (*est_power_get)(const struct scmi_protocol_handle *ph, u32
domain, unsigned long *rate, unsigned long *power);
    bool (*fast_switch_possible)(const struct scmi_protocol_handle *ph,
u32 domain);
    int (*fast_switch_rate_limit)(const struct scmi_protocol_handle *ph,
u32 domain, u32 *rate_limit);
    enum scmi_power_scale (*power_scale_get)(const struct
scmi_protocol_handle *ph);
 };

lowkey obsessed with how every single one of these takes a const struct scmi_protocol_handle *ph btw. consistent king πŸ‘‘


🌸 MEMBERS 🌸

time for the cast list, main-character energy only ✨

  • num_domains_get β€” gets the number of supported performance domains. like, how many lil guys are we working with πŸ”₯
  • info_get β€” get the information of a performance domain. also heads up, it's marked __must_check, so bestie... you must check it πŸ™ˆ
  • limits_set β€” sets limits on the performance level of a domain. max and min, respectfully πŸ’…
  • limits_get β€” gets limits on the performance level of a domain. same energy, read direction πŸ“–
  • level_set β€” sets the performance level of a domain. yes the bool poll is part of the deal 🀝
  • level_get β€” gets the performance level of a domain. also got a bool poll, iykyk 🧚
  • transition_latency_get β€” gets the DVFS transition latency for a given device ⏱️
  • rate_limit_get β€” gets the minimum time (us) required between successive requests. tiny numbers, big feelings πŸ“
  • device_opps_add β€” adds all the OPPs for a given device. all of them, no half-sending πŸŽ€
  • freq_set β€” sets the frequency for a given device using sustained frequency to sustained performance level mapping. say that five times fast 😭
  • freq_get β€” gets the frequency for a given device using sustained frequency to sustained performance level mapping. same mapping, other direction, slay 🌈
  • est_power_get β€” gets the estimated power cost for a given performance domain at a given frequency. estimates only, don't come for me ⚑
  • fast_switch_possible β€” indicates if fast DVFS switching is possible or not for a given device. returns a bool, very yes-or-no of it ✌️
  • fast_switch_rate_limit β€” gets the minimum time (us) required between successive fast_switching requests. notice: fast. still rate limited. balance πŸ”₯
  • power_scale_get β€” indicates if the power values provided are in milliWatts or in some other (abstract) scale. abstract scale bestie, we don't know her either πŸ’€

πŸ‘‘ SEE ALSO πŸ‘‘

the whole friend group fr fr β€” the kernel file lives at ./include/linux/scmi_protocol.h, and then:

  • struct scmi_base_info(9)
  • struct scmi_clk_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_powercap_proto_ops(9)
  • struct scmi_pinctrl_proto_ops(9)
  • struct scmi_notify_ops(9)
  • struct scmi_handle(9)
  • module_scmi_driver(9)
  • module_scmi_protocol(9)

ngl, read the whole gang before you go poking at performance ops, mkay? 🫢

and that's the page!! footer tea for the very end: this one comes from ./include/linux, dated October 2026, and it's filed under struct scmi_perf_proto_ops(9) β€” mwah, bye bestie πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from