From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
"Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>,
"Danilo Krummrich" <dakr@redhat.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Viresh Kumar" <vireshk@kernel.org>, "Nishanth Menon" <nm@ti.com>,
"Stephen Boyd" <sboyd@kernel.org>
Cc: "Viresh Kumar" <viresh.kumar@linaro.org>,
linux-pm@vger.kernel.org,
"Vincent Guittot" <vincent.guittot@linaro.org>,
rust-for-linux@vger.kernel.org,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Joakim Bech" <joakim.bech@linaro.org>,
"Rob Herring" <robh@kernel.org>,
"Yury Norov" <yury.norov@gmail.com>,
"Burak Emir" <bqe@google.com>,
"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Russell King" <linux@armlinux.org.uk>,
linux-clk@vger.kernel.org,
"Michael Turquette" <mturquette@baylibre.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH V11 08/15] rust: opp: Add initial abstractions for OPP framework
Date: Mon, 21 Apr 2025 12:52:15 +0530 [thread overview]
Message-ID: <7d085916e9c9548aef96ccb07ce709122a0be6cd.1745218975.git.viresh.kumar@linaro.org> (raw)
In-Reply-To: <cover.1745218975.git.viresh.kumar@linaro.org>
Introduce initial Rust abstractions for the Operating Performance Points
(OPP) framework. This includes bindings for `struct dev_pm_opp` and
`struct dev_pm_opp_data`, laying the groundwork for further OPP
integration.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
MAINTAINERS | 1 +
rust/bindings/bindings_helper.h | 1 +
rust/kernel/lib.rs | 2 +
rust/kernel/opp.rs | 299 ++++++++++++++++++++++++++++++++
4 files changed, 303 insertions(+)
create mode 100644 rust/kernel/opp.rs
diff --git a/MAINTAINERS b/MAINTAINERS
index 475abf72869c..931e418f89ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18165,6 +18165,7 @@ F: Documentation/devicetree/bindings/opp/
F: Documentation/power/opp.rst
F: drivers/opp/
F: include/linux/pm_opp.h
+F: rust/kernel/opp.rs
OPL4 DRIVER
M: Clemens Ladisch <clemens@ladisch.de>
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index ac92c67d2c38..529f22891e0b 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -30,6 +30,7 @@
#include <linux/phy.h>
#include <linux/pid_namespace.h>
#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
#include <linux/poll.h>
#include <linux/property.h>
#include <linux/refcount.h>
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index db372f806875..11d333c8c673 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -68,6 +68,8 @@
#[cfg(CONFIG_NET)]
pub mod net;
pub mod of;
+#[cfg(CONFIG_PM_OPP)]
+pub mod opp;
pub mod page;
#[cfg(CONFIG_PCI)]
pub mod pci;
diff --git a/rust/kernel/opp.rs b/rust/kernel/opp.rs
new file mode 100644
index 000000000000..8f0493a8b6e8
--- /dev/null
+++ b/rust/kernel/opp.rs
@@ -0,0 +1,299 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Operating performance points.
+//!
+//! This module provides rust abstractions for interacting with the OPP subsystem.
+//!
+//! C header: [`include/linux/pm_opp.h`](srctree/include/linux/pm_opp.h)
+//!
+//! Reference: <https://docs.kernel.org/power/opp.html>
+
+use crate::{
+ clk::Hertz,
+ device::Device,
+ error::{code::*, to_result, Result},
+ ffi::c_ulong,
+ types::{ARef, AlwaysRefCounted, Opaque},
+};
+
+use core::ptr;
+
+/// The voltage unit.
+///
+/// Represents voltage in microvolts, wrapping a [`c_ulong`] value.
+///
+/// ## Examples
+///
+/// ```
+/// use kernel::opp::MicroVolt;
+///
+/// let raw = 90500;
+/// let volt = MicroVolt(raw);
+///
+/// assert_eq!(usize::from(volt), raw);
+/// assert_eq!(volt, MicroVolt(raw));
+/// ```
+#[derive(Copy, Clone, PartialEq, Eq, Debug)]
+pub struct MicroVolt(pub c_ulong);
+
+impl From<MicroVolt> for c_ulong {
+ #[inline]
+ fn from(volt: MicroVolt) -> Self {
+ volt.0
+ }
+}
+
+/// The power unit.
+///
+/// Represents power in microwatts, wrapping a [`c_ulong`] value.
+///
+/// ## Examples
+///
+/// ```
+/// use kernel::opp::MicroWatt;
+///
+/// let raw = 1000000;
+/// let power = MicroWatt(raw);
+///
+/// assert_eq!(usize::from(power), raw);
+/// assert_eq!(power, MicroWatt(raw));
+/// ```
+#[derive(Copy, Clone, PartialEq, Eq, Debug)]
+pub struct MicroWatt(pub c_ulong);
+
+impl From<MicroWatt> for c_ulong {
+ #[inline]
+ fn from(power: MicroWatt) -> Self {
+ power.0
+ }
+}
+
+/// Handle for a dynamically created [`OPP`].
+///
+/// The associated [`OPP`] is automatically removed when the [`Token`] is dropped.
+///
+/// ## Examples
+///
+/// The following example demonstrates how to create an [`OPP`] dynamically.
+///
+/// ```
+/// use kernel::clk::Hertz;
+/// use kernel::device::Device;
+/// use kernel::error::Result;
+/// use kernel::opp::{Data, MicroVolt, Token};
+/// use kernel::types::ARef;
+///
+/// fn create_opp(dev: &ARef<Device>, freq: Hertz, volt: MicroVolt, level: u32) -> Result<Token> {
+/// let data = Data::new(freq, volt, level, false);
+///
+/// // OPP is removed once token goes out of scope.
+/// data.add_opp(dev)
+/// }
+/// ```
+pub struct Token {
+ dev: ARef<Device>,
+ freq: Hertz,
+}
+
+impl Token {
+ /// Dynamically adds an [`OPP`] and returns a [`Token`] that removes it on drop.
+ fn new(dev: &ARef<Device>, mut data: Data) -> Result<Self> {
+ // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety
+ // requirements.
+ to_result(unsafe { bindings::dev_pm_opp_add_dynamic(dev.as_raw(), &mut data.0) })?;
+ Ok(Self {
+ dev: dev.clone(),
+ freq: data.freq(),
+ })
+ }
+}
+
+impl Drop for Token {
+ fn drop(&mut self) {
+ // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety
+ // requirements.
+ unsafe { bindings::dev_pm_opp_remove(self.dev.as_raw(), self.freq.into()) };
+ }
+}
+
+/// OPP data.
+///
+/// Rust abstraction for the C `struct dev_pm_opp_data`, used to define operating performance
+/// points (OPPs) dynamically.
+///
+/// ## Examples
+///
+/// The following example demonstrates how to create an [`OPP`] with [`Data`].
+///
+/// ```
+/// use kernel::clk::Hertz;
+/// use kernel::device::Device;
+/// use kernel::error::Result;
+/// use kernel::opp::{Data, MicroVolt, Token};
+/// use kernel::types::ARef;
+///
+/// fn create_opp(dev: &ARef<Device>, freq: Hertz, volt: MicroVolt, level: u32) -> Result<Token> {
+/// let data = Data::new(freq, volt, level, false);
+///
+/// // OPP is removed once token goes out of scope.
+/// data.add_opp(dev)
+/// }
+/// ```
+#[repr(transparent)]
+pub struct Data(bindings::dev_pm_opp_data);
+
+impl Data {
+ /// Creates a new instance of [`Data`].
+ ///
+ /// This can be used to define a dynamic OPP to be added to a device.
+ pub fn new(freq: Hertz, volt: MicroVolt, level: u32, turbo: bool) -> Self {
+ Self(bindings::dev_pm_opp_data {
+ turbo,
+ freq: freq.into(),
+ u_volt: volt.into(),
+ level,
+ })
+ }
+
+ /// Adds an [`OPP`] dynamically.
+ ///
+ /// Returns a [`Token`] that ensures the OPP is automatically removed
+ /// when it goes out of scope.
+ #[inline]
+ pub fn add_opp(self, dev: &ARef<Device>) -> Result<Token> {
+ Token::new(dev, self)
+ }
+
+ /// Returns the frequency associated with this OPP data.
+ #[inline]
+ fn freq(&self) -> Hertz {
+ Hertz(self.0.freq)
+ }
+}
+
+/// A reference-counted Operating performance point (OPP).
+///
+/// Rust abstraction for the C `struct dev_pm_opp`.
+///
+/// # Invariants
+///
+/// The pointer stored in `Self` is non-null and valid for the lifetime of the [`OPP`].
+///
+/// Instances of this type are reference-counted. The reference count is incremented by the
+/// `dev_pm_opp_get` function and decremented by `dev_pm_opp_put`. The Rust type `ARef<OPP>`
+/// represents a pointer that owns a reference count on the [`OPP`].
+///
+/// A reference to the [`OPP`], &[`OPP`], isn't refcounted by the Rust code.
+#[repr(transparent)]
+pub struct OPP(Opaque<bindings::dev_pm_opp>);
+
+/// SAFETY: It is okay to send the ownership of [`OPP`] across thread boundaries.
+unsafe impl Send for OPP {}
+
+/// SAFETY: It is okay to access [`OPP`] through shared references from other threads because we're
+/// either accessing properties that don't change or that are properly synchronised by C code.
+unsafe impl Sync for OPP {}
+
+/// SAFETY: The type invariants guarantee that [`OPP`] is always refcounted.
+unsafe impl AlwaysRefCounted for OPP {
+ fn inc_ref(&self) {
+ // SAFETY: The existence of a shared reference means that the refcount is nonzero.
+ unsafe { bindings::dev_pm_opp_get(self.0.get()) };
+ }
+
+ unsafe fn dec_ref(obj: ptr::NonNull<Self>) {
+ // SAFETY: The safety requirements guarantee that the refcount is nonzero.
+ unsafe { bindings::dev_pm_opp_put(obj.cast().as_ptr()) }
+ }
+}
+
+impl OPP {
+ /// Creates an owned reference to a [`OPP`] from a valid pointer.
+ ///
+ /// The refcount is incremented by the C code and will be decremented by `dec_ref` when the
+ /// [`ARef`] object is dropped.
+ ///
+ /// # Safety
+ ///
+ /// The caller must ensure that `ptr` is valid and the refcount of the [`OPP`] is incremented.
+ /// The caller must also ensure that it doesn't explicitly drop the refcount of the [`OPP`], as
+ /// the returned [`ARef`] object takes over the refcount increment on the underlying object and
+ /// the same will be dropped along with it.
+ pub unsafe fn from_raw_opp_owned(ptr: *mut bindings::dev_pm_opp) -> Result<ARef<Self>> {
+ let ptr = ptr::NonNull::new(ptr).ok_or(ENODEV)?;
+
+ // SAFETY: The safety requirements guarantee the validity of the pointer.
+ //
+ // INVARIANT: The reference-count is decremented when [`OPP`] goes out of scope.
+ Ok(unsafe { ARef::from_raw(ptr.cast()) })
+ }
+
+ /// Creates a reference to a [`OPP`] from a valid pointer.
+ ///
+ /// The refcount is not updated by the Rust API unless the returned reference is converted to
+ /// an [`ARef`] object.
+ ///
+ /// # Safety
+ ///
+ /// The caller must ensure that `ptr` is valid and remains valid for the duration of `'a`.
+ #[inline]
+ pub unsafe fn from_raw_opp<'a>(ptr: *mut bindings::dev_pm_opp) -> Result<&'a Self> {
+ // SAFETY: The caller guarantees that the pointer is not dangling and stays valid for the
+ // duration of 'a. The cast is okay because [`OPP`] is `repr(transparent)`.
+ Ok(unsafe { &*ptr.cast() })
+ }
+
+ #[inline]
+ fn as_raw(&self) -> *mut bindings::dev_pm_opp {
+ self.0.get()
+ }
+
+ /// Returns the frequency of an [`OPP`].
+ pub fn freq(&self, index: Option<u32>) -> Hertz {
+ let index = index.unwrap_or(0);
+
+ // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
+ // use it.
+ Hertz(unsafe { bindings::dev_pm_opp_get_freq_indexed(self.as_raw(), index) })
+ }
+
+ /// Returns the voltage of an [`OPP`].
+ #[inline]
+ pub fn voltage(&self) -> MicroVolt {
+ // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
+ // use it.
+ MicroVolt(unsafe { bindings::dev_pm_opp_get_voltage(self.as_raw()) })
+ }
+
+ /// Returns the level of an [`OPP`].
+ #[inline]
+ pub fn level(&self) -> u32 {
+ // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
+ // use it.
+ unsafe { bindings::dev_pm_opp_get_level(self.as_raw()) }
+ }
+
+ /// Returns the power of an [`OPP`].
+ #[inline]
+ pub fn power(&self) -> MicroWatt {
+ // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
+ // use it.
+ MicroWatt(unsafe { bindings::dev_pm_opp_get_power(self.as_raw()) })
+ }
+
+ /// Returns the required pstate of an [`OPP`].
+ #[inline]
+ pub fn required_pstate(&self, index: u32) -> u32 {
+ // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
+ // use it.
+ unsafe { bindings::dev_pm_opp_get_required_pstate(self.as_raw(), index) }
+ }
+
+ /// Returns true if the [`OPP`] is turbo.
+ #[inline]
+ pub fn is_turbo(&self) -> bool {
+ // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
+ // use it.
+ unsafe { bindings::dev_pm_opp_is_turbo(self.as_raw()) }
+ }
+}
--
2.31.1.272.g89b43f80a514
next prev parent reply other threads:[~2025-04-21 7:23 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 7:22 [PATCH V11 00/15] Rust abstractions for clk, cpumask, cpufreq, OPP Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 01/15] rust: cpumask: Add few more helpers Viresh Kumar
2025-05-02 16:56 ` Yury Norov
2025-04-21 7:22 ` [PATCH V11 02/15] rust: cpumask: Add initial abstractions Viresh Kumar
2025-05-02 17:01 ` Yury Norov
2025-04-21 7:22 ` [PATCH V11 03/15] MAINTAINERS: Add entry for Rust cpumask API Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 04/15] rust: clk: Add helpers for Rust code Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 05/15] rust: clk: Add initial abstractions Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 06/15] rust: macros: enable use of hyphens in module names Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 07/15] rust: cpu: Add from_cpu() Viresh Kumar
2025-04-21 7:22 ` Viresh Kumar [this message]
2025-04-21 7:22 ` [PATCH V11 09/15] rust: opp: Add abstractions for the OPP table Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 10/15] rust: opp: Add abstractions for the configuration options Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 11/15] rust: cpufreq: Add initial abstractions for cpufreq framework Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 12/15] rust: cpufreq: Extend abstractions for policy and driver ops Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 13/15] rust: cpufreq: Extend abstractions for driver registration Viresh Kumar
2025-04-23 12:05 ` Danilo Krummrich
2025-04-24 6:01 ` Viresh Kumar
2025-04-23 12:08 ` Danilo Krummrich
2025-04-24 6:29 ` Viresh Kumar
2025-04-24 8:03 ` Danilo Krummrich
2025-04-24 10:51 ` Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 14/15] rust: opp: Extend OPP abstractions with cpufreq support Viresh Kumar
2025-04-21 7:22 ` [PATCH V11 15/15] cpufreq: Add Rust-based cpufreq-dt driver Viresh Kumar
2025-05-02 7:01 ` [PATCH V11 00/15] Rust abstractions for clk, cpumask, cpufreq, OPP Viresh Kumar
2025-05-06 10:13 ` Andrew Ballance
2025-05-06 10:25 ` Miguel Ojeda
2025-05-08 2:10 ` Viresh Kumar
2025-05-08 2:52 ` Philip Li
2025-05-19 5:12 ` Viresh Kumar
2025-05-09 8:43 ` Miguel Ojeda
2025-05-13 11:15 ` Viresh Kumar
2025-05-19 5:00 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7d085916e9c9548aef96ccb07ce709122a0be6cd.1745218975.git.viresh.kumar@linaro.org \
--to=viresh.kumar@linaro.org \
--cc=a.hindborg@kernel.org \
--cc=alex.bennee@linaro.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bqe@google.com \
--cc=dakr@kernel.org \
--cc=dakr@redhat.com \
--cc=gary@garyguo.net \
--cc=joakim.bech@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linux@rasmusvillemoes.dk \
--cc=manos.pitsidianakis@linaro.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mturquette@baylibre.com \
--cc=nm@ti.com \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tmgross@umich.edu \
--cc=vincent.guittot@linaro.org \
--cc=vireshk@kernel.org \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).