-
Notifications
You must be signed in to change notification settings - Fork 34
Add Dynamic Voltage and Frequency Scaling Driver Class #567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
0f37200
9df0961
e488171
47f5739
7fd3db7
dd88f5f
c53cc75
9ef2269
c921a17
a063a52
06a5494
1882a01
50a87d3
024ff39
a283186
594cb78
aeadcf5
91e0f16
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,6 +20,7 @@ ci_logs/ | |
| zig-out/ | ||
| .zig-cache/ | ||
| venv/ | ||
| target/ | ||
| __pycache__ | ||
| .*.sw* | ||
| *.dtb | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2542,9 +2542,92 @@ \subsection{Status} | |
|
|
||
| This device-class specification is \textbf{subject to change}. | ||
|
|
||
| \section{Dynamic Voltage and Frequency Scaling}\label{s:DVFS} | ||
| Dynamic Voltage and Frequency Scaling(DVFS) is a power management technology | ||
| to adjust the frequency and the voltage applied on the processing units in runtime | ||
| depending on the actual needs. | ||
|
|
||
| \subsection{Principle of the operation} | ||
| The power consumption of CMOS(Complementary Metal-Oxide-Semiconductor) circuits can | ||
| be defined by the following formula: | ||
|
|
||
| \begin{equation} | ||
| P_{total} = P_{dynamic} + P_{static} | ||
| \end{equation} | ||
|
|
||
| Where dynamic power can be roughly defined as: | ||
|
|
||
| \begin{equation} | ||
| P_{dynamic} \approx C \cdot V^2 \cdot f | ||
| \end{equation} | ||
|
|
||
| \begin{itemize} | ||
| \item \textbf{C}: Capacitance (fixed by hardware design). | ||
| \item \textbf{V}: Supply Voltage. | ||
| \item \textbf{f}: Clock Frequency. | ||
| \end{itemize} | ||
|
|
||
| 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. | ||
|
|
||
| \subsection{Implementing DVFS on different platforms} | ||
| There are generally two ways to implement DVFS, and which one to use is heavily depended | ||
| on the hardware platform. | ||
|
|
||
| \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. | ||
|
|
||
| \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. | ||
|
Comment on lines
+2582
to
+2585
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this make any sense to include here if we don't use it at all?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is possible that we might have a board that actually supports SCMI in the future, though. |
||
|
|
||
| \subsection{Data Structures and Interface Specification} | ||
| The interface contains static configuration tables to describe the hardware. These are | ||
| exposed to the client at compile time. | ||
|
|
||
| \paragraph{Operating Performance Point} | ||
| Describes a valid discrete state the processing unit can operate on. | ||
| \begin{lstlisting} | ||
| typedef struct { | ||
| uint64_t freq_hz; // Target Frequency in Hertz | ||
| uint64_t voltage_uv; // Target Voltage in Microvolts | ||
| uint64_t latency_ns; // Transition latency in Nanoseconds | ||
| } OppEntry; | ||
| \end{lstlisting} | ||
|
|
||
| \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} | ||
|
Comment on lines
+2601
to
+2615
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
|
|
||
| The interface for DVFS uses \gls{ppc}, and has the following | ||
| procedures that can be called: | ||
| \begin{description} | ||
| \item[\texttt{get\_freq(core\_identifier)}] | ||
| Retrieves the current actual frequency of a specific processing unit. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Remove "actual" |
||
| \item[\texttt{set\_freq(core\_identifier, frequency)}] | ||
| Sets the designated processing unit to a specific target frequency. The frequency | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Remove "specific" |
||
| must be a valid value from the opp table for that specific core or the request | ||
| will be rejected. | ||
| \end{description} | ||
|
|
||
| \section{Sensors, PWM, GPIO, etc}\label{s:sensors} | ||
|
|
||
| These device classes are all very similar, and tend tend to be low | ||
| These device classes are all very similar, and tend to be low | ||
| bandwidth --- transferring one bit to a few bytes at a time. They | ||
| fall into the ``simple device'' category introduced in | ||
| \autoref{s:dr-overview}; rather than | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| # Copyright 2025, UNSW | ||
| # SPDX-License-Identifier: BSD-2-Clause | ||
|
|
||
| [build] | ||
| target = "../../support/targets/aarch64-sel4-microkit-minimal.json" | ||
|
|
||
| [unstable] | ||
| build-std = ["core", "compiler_builtins", "alloc"] | ||
| build-std-features = ["compiler-builtins-mem"] | ||
|
|
||
| [net] | ||
| git-fetch-with-cli = true | ||
|
|
||
| [target."aarch64-sel4-microkit-minimal"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How else would it work?