Add Dynamic Voltage and Frequency Scaling Driver Class by Cheng-Li1 · Pull Request #567 · au-ts/sddf

Cheng-Li1 · 2025-11-19T03:25:54Z

Add the DVFS(Dynamic Voltage and Frequency Scaling) driver class and associated interfaces, and the implementation of the DVFS driver for the ZCU102 platform.

Signed-off-by: Cheng <lichengchaoreng@gmail.com>

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

midnightveil · 2025-11-19T03:29:58Z

Same comment as previous: is there a design written up for this that we can look at?

Cheng-Li1 · 2025-11-19T03:33:04Z

Same comment as previous: is there a design written up for this that we can look at?

Writing the doc now. Should be available soon.

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Cheng-Li1 · 2025-11-26T05:34:16Z

I have added a section about DVFS in the design doc.

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

omeh-a · 2026-02-25T05:51:13Z

The description of what DVFS in the design doc could use a prune. Dynamic and static power (static in particular) aren't super important and things like defining CMOS seem totally irrelevant (all semiconductors have dynamic and static power usage!). I would drop the static power bits and just go straight into "The dynamic power of a computer is roughly given by ...."

The equation for dynamic power is also wrong as it omits the activity factor, but tbh I think that doesn't really matter. I would reword the description below however as it is misleading

The power scales linearly with the frequency and quadratically with voltage. Lowering the frequency, which usually allows a lower supply voltage, can dramatically lower the power consumption as well as the generated heat.

Power itself has a quadratic relationship to voltage when current is omitted (P=V^2/R), but crucially the voltage doesn't "scale" in the same way frequency does. There simply needs to be sufficient voltage for all transistors to switch at a given frequency (as you already point out).

I think you should just omit mentioning the linear vs exponential scaling because this might cause a reader to falsely conclude that these are independent quantities, when in reality a truer expression of dynamic power should express voltage as a function of frequency since it should be minimised.

omeh-a · 2026-02-26T23:43:04Z

+
+\paragraph{Direct interact with the clock/regulator:} The DVFS driver directly interacts
+with the clock and the regulator that control the frequency and the voltage the processing
+units are operating on. This approach is used on most of the ARM or RISC-V platforms.


How else would it work?

omeh-a · 2026-02-26T23:45:08Z

+procedures that can be called:
+\begin{description}
+  \item[\texttt{get\_freq(core\_identifier)}]
+  Retrieves the current actual frequency of a specific processing unit.


Remove "actual"

omeh-a · 2026-02-26T23:45:20Z

+  \item[\texttt{get\_freq(core\_identifier)}]
+  Retrieves the current actual frequency of a specific processing unit.
+  \item[\texttt{set\_freq(core\_identifier, frequency)}]
+  Sets the designated processing unit to a specific target frequency. The frequency


Remove "specific"

omeh-a · 2026-02-26T23:53:46Z

~~This driver also doesn't match the form of the sDDF's directory structure, you should move all current work to drivers/dvfs/{platform}/~~

I see that cpufreq implements this internally ... still seems clumsy this way though. Maybe it should be in drivers/dvfs/rust? @Ivan-Velickovic maybe you have thoughts. It certainly needs to move anyway to have the C driver coexist.

Third note ... I see that this driver actually hardcodes Xilinx things so just making it rust would also be wrong. I will just make it zcu102 in my branch based on this.

omeh-a · 2026-03-02T00:13:48Z

+
+#[derive(Debug)]
+pub enum Error {
+    EINVAL = 0,


I am not a rust person ... but what is the point of this error? Isn't it simpler to use a builtin error type given that this enum only has one member?

Yeah, I agree that it would be better to use a standardized error type instead of having their own error types in the driver. The thing is that I don't think(I might be wrong) that there is a built-in error enum in Rust, nor is there a universal error enum in our system. I would be more than happy to switch to a universal error enum in our system.

omeh-a · 2026-03-02T00:14:29Z

+// SPDX-License-Identifier: BSD-2-Clause
+
+#[derive(Debug)]
+pub struct OppEntry {


Should rename this to OpEntry for clarity, since "Operating point" only has one P :P

midnightveil

The design notes should be improved.

midnightveil · 2026-03-02T01:47:30Z

+\paragraph{Core Configuration (CoreInfo)}
+Describes the topology of the processor. The configuration describes
+the number of the processing units, the clock source they are operating under
+(one clock source may provide clock for multiple processing units, which means
+changing the frequency for one unit would change the frequency of all the units
+which has the same clock source), and the Operating Performance Point table.
+
+\begin{lstlisting}
+typedef struct {
+    uint64_t core_ident;         // Logical Core ID
+    uint64_t clock_source_ident; // ID of the clock source
+    const OppEntry *opptable;    // Pointer to valid OPPs for this core
+    size_t opptable_len;         // Number of OPPs
+} CoreInfo;
+\end{lstlisting}


Peter cleared this up for me: the reason why we have this structure is because this is how the DTS describes things.

The reason why we have described things in terms of this structure is because this is how the DTS does generically for Linux. I think we should be explicit about this.

Yeah, Lesley told me that it would be best to read the struct from the dts. For now, I will stress this structure and the info is derived from Linux DTS.

midnightveil · 2026-03-02T01:47:47Z

+\paragraph{Firmware Abstraction:} For some very new ARM platforms, System Control and
+Management Interface (SCMI) is supported, providing a unified framework to manage the
+the power state of the processing units. For x86 platforms, ACPI and HWP are the common
+framework to provide platform agnostic power management interfaces.


Does this make any sense to include here if we don't use it at all?

It is possible that we might have a board that actually supports SCMI in the future, though.

midnightveil · 2026-03-02T01:49:08Z

+    EINVAL = 0,
+}
+
+pub trait FreqOps {


This doesn't need to be a trait.

As I've mentioned before, our API is cross-process, not through code.

There's zero reason for a trait here, especially not one with a bunch of helpers that have panic!() for no reason.

The trait defines the behaviors of the drivers, and the drivers following the sddf protocol do not necessarily mean that the driver cannot have a set of behaviors that they need to follow internally. I can ask around to see whether others are unsatisfied with the design, and if so, I will change it.

The trait is unnecessary, though?

midnightveil · 2026-03-02T01:49:25Z

+#![no_std] // Don't link the standard library
+#![no_main] // Don't use the default entry point


Again as I've mentioned this before you don't need to say what these are.

midnightveil · 2026-03-02T01:50:18Z

+cpufreq = { path = "cpufreq" }
+sddf-rust = { path = "../../include/sddf-rust" }
+sel4-microkit = { git = "https://github.com/seL4/rust-sel4.git", tag = "v3.0.0" }
+sddf-ipc-types = { git = "https://github.com/seL4/rust-sel4.git", tag = "v3.0.0" }


(code nit) these should be part of workspace dependenies for the whole of seL4, and should not hardcode relative paths.

midnightveil · 2026-03-02T01:50:28Z

+[toolchain]
+channel = "nightly-2025-10-20"
+profile = "default"
+components = [
+    "rust-src",
+    "rustc-dev",
+    "llvm-tools-preview",
+    "rust-analyzer",
+]
+targets = [
+    "x86_64-unknown-linux-musl",
+    "aarch64-unknown-linux-musl",
+    "armv7-unknown-linux-musleabi",
+    "riscv64gc-unknown-linux-musl",
+    # tier 2, not available via rustup
+    # "riscv32gc-unknown-linux-musl",
+]


midnightveil · 2026-03-02T01:51:02Z

+	echo "MICROKIT SDK config directory: $(microkit_sdk_config_dir)" && \
+	echo "SEl4 include directories: $(sel4_include_dirs)" && \


these echo are unneededed

omeh-a · 2026-03-04T04:36:25Z

+ * @param core_ident The unique identifier of the CPU core.
+ * @param freq A pointer to a unsighed integer to pass back the returned frequency.
+ */
+static inline int32_t sddf_dvfs_get_freq(unsigned int channel, uint64_t core_ident, uint64_t *freq)


There is a critical problem of motivation with this protocol: why are we giving frequencies at all? This driver is meant to change the voltage AND frequency, and more importantly it can only do that for values in the operating point table. Surely we should be setting an operating point index instead right?

omeh-a · 2026-05-21T01:40:40Z

This PR is now redundant due to #667 - this version doesn't have a design that is portable to other platforms and isn't mergable due to the state of our rust support. Given that this PR has remained untouched for months and is replaced, I think we should close this PR

omeh-a · 2026-06-04T02:46:22Z

Closing as this PR is redundant.

Cheng-Li1 and others added 11 commits November 18, 2025 14:56

Draft of the dvfs example

0f37200

Signed-off-by: Cheng <lichengchaoreng@gmail.com>

Add timer driver interface in Rust

9df0961

Signed-off-by: Cheng <lichengchaoreng@gmail.com>

Update rust-sel4 for timer

e488171

Signed-off-by: Cheng <lichengchaoreng@gmail.com>

Successfully validated the correctness of the DVFS driver for ZCU102

47f5739

Signed-off-by: Cheng <lichengchaoreng@gmail.com>

Add C version of DVFS interfaces.

7fd3db7

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Add C version of DVFS example and modify the name of functions.

dd88f5f

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Minor change to the dvfs client.

c53cc75

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Integrate the changes from the DVFS driver.

9ef2269

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

The example compiles, still needs the ZCU102 to test.

c921a17

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Still have some minor issues.

a063a52

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Example fully working.

06a5494

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Cheng-Li1 added 2 commits November 19, 2025 15:00

Deal with format and license issues.

1882a01

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Try to fix the license issue.

50a87d3

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Cheng-Li1 force-pushed the freq-scaling-example branch from 884d1cb to 50a87d3 Compare November 19, 2025 04:09

Cheng-Li1 added 3 commits November 25, 2025 16:24

Add comments. The docs are still WIP.

024ff39

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Add DVFS section to the design doc.

a283186

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Update the DVFS section in the design doc.

594cb78

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Cheng-Li1 marked this pull request as ready for review November 26, 2025 05:34

Cheng-Li1 added 2 commits November 27, 2025 11:27

Update the driver to use microkit 2.1.0 and Rust-Sel4 3.0

aeadcf5

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

Fix the json format.

91e0f16

Signed-off-by: Cheng Li <cheng.li10@unsw.edu.au>

omeh-a reviewed Feb 26, 2026

View reviewed changes

omeh-a reviewed Mar 2, 2026

View reviewed changes

midnightveil requested changes Mar 2, 2026

View reviewed changes

omeh-a reviewed Mar 4, 2026

View reviewed changes

omeh-a mentioned this pull request Mar 12, 2026

Maaxboard dvfs #667

Draft

5 tasks

omeh-a closed this Jun 4, 2026

		#![no_std] // Don't link the standard library
		#![no_main] // Don't use the default entry point

		echo "MICROKIT SDK config directory: $(microkit_sdk_config_dir)" && \
		echo "SEl4 include directories: $(sel4_include_dirs)" && \

Uh oh!

Conversation

Cheng-Li1 commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

midnightveil commented Nov 19, 2025

Uh oh!

Cheng-Li1 commented Nov 19, 2025

Uh oh!

Cheng-Li1 commented Nov 26, 2025

Uh oh!

omeh-a commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

omeh-a commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

midnightveil left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

omeh-a commented May 21, 2026

Uh oh!

omeh-a commented Jun 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Cheng-Li1 commented Nov 19, 2025 •

edited

Loading

omeh-a commented Feb 25, 2026 •

edited

Loading

omeh-a commented Feb 26, 2026 •

edited

Loading