mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
249 lines
10 KiB
249 lines
10 KiB
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) |
|
%YAML 1.2 |
|
--- |
|
$id: http://devicetree.org/schemas/opp/opp-v2-base.yaml# |
|
$schema: http://devicetree.org/meta-schemas/core.yaml# |
|
|
|
title: Generic OPP (Operating Performance Points) Common Binding |
|
|
|
maintainers: |
|
- Viresh Kumar <[email protected]> |
|
|
|
description: | |
|
Devices work at voltage-current-frequency combinations and some implementations |
|
have the liberty of choosing these. These combinations are called Operating |
|
Performance Points aka OPPs. This document defines bindings for these OPPs |
|
applicable across wide range of devices. For illustration purpose, this document |
|
uses CPU as a device. |
|
|
|
This describes the OPPs belonging to a device. |
|
|
|
select: false |
|
|
|
properties: |
|
$nodename: |
|
pattern: '^opp-table(-[a-z0-9]+)?$' |
|
|
|
opp-shared: |
|
description: |
|
Indicates that device nodes using this OPP Table Node's phandle switch |
|
their DVFS state together, i.e. they share clock/voltage/current lines. |
|
Missing property means devices have independent clock/voltage/current |
|
lines, but they share OPP tables. |
|
type: boolean |
|
|
|
patternProperties: |
|
'^opp(-?[0-9]+)*$': |
|
type: object |
|
description: |
|
One or more OPP nodes describing voltage-current-frequency combinations. |
|
Their name isn't significant but their phandle can be used to reference an |
|
OPP. These are mandatory except for the case where the OPP table is |
|
present only to indicate dependency between devices using the opp-shared |
|
property. |
|
|
|
properties: |
|
opp-hz: |
|
description: |
|
Frequency in Hz, expressed as a 64-bit big-endian integer. This is a |
|
required property for all device nodes, unless another "required" |
|
property to uniquely identify the OPP nodes exists. Devices like power |
|
domains must have another (implementation dependent) property. |
|
|
|
Entries for multiple clocks shall be provided in the same field, as |
|
array of frequencies. The OPP binding doesn't provide any provisions |
|
to relate the values to their clocks or the order in which the clocks |
|
need to be configured and that is left for the implementation |
|
specific binding. |
|
minItems: 1 |
|
maxItems: 16 |
|
items: |
|
maxItems: 1 |
|
|
|
opp-microvolt: |
|
description: | |
|
Voltage for the OPP |
|
|
|
A single regulator's voltage is specified with an array of size one or three. |
|
Single entry is for target voltage and three entries are for <target min max> |
|
voltages. |
|
|
|
Entries for multiple regulators shall be provided in the same field separated |
|
by angular brackets <>. The OPP binding doesn't provide any provisions to |
|
relate the values to their power supplies or the order in which the supplies |
|
need to be configured and that is left for the implementation specific |
|
binding. |
|
|
|
Entries for all regulators shall be of the same size, i.e. either all use a |
|
single value or triplets. |
|
minItems: 1 |
|
maxItems: 8 # Should be enough regulators |
|
items: |
|
minItems: 1 |
|
maxItems: 3 |
|
|
|
opp-microamp: |
|
description: | |
|
The maximum current drawn by the device in microamperes considering |
|
system specific parameters (such as transients, process, aging, |
|
maximum operating temperature range etc.) as necessary. This may be |
|
used to set the most efficient regulator operating mode. |
|
|
|
Should only be set if opp-microvolt or opp-microvolt-<name> is set for |
|
the OPP. |
|
|
|
Entries for multiple regulators shall be provided in the same field |
|
separated by angular brackets <>. If current values aren't required |
|
for a regulator, then it shall be filled with 0. If current values |
|
aren't required for any of the regulators, then this field is not |
|
required. The OPP binding doesn't provide any provisions to relate the |
|
values to their power supplies or the order in which the supplies need |
|
to be configured and that is left for the implementation specific |
|
binding. |
|
minItems: 1 |
|
maxItems: 8 # Should be enough regulators |
|
|
|
opp-microwatt: |
|
description: | |
|
The power for the OPP in micro-Watts. |
|
|
|
Entries for multiple regulators shall be provided in the same field |
|
separated by angular brackets <>. If current values aren't required |
|
for a regulator, then it shall be filled with 0. If power values |
|
aren't required for any of the regulators, then this field is not |
|
required. The OPP binding doesn't provide any provisions to relate the |
|
values to their power supplies or the order in which the supplies need |
|
to be configured and that is left for the implementation specific |
|
binding. |
|
minItems: 1 |
|
maxItems: 8 # Should be enough regulators |
|
|
|
opp-level: |
|
description: |
|
A value representing the performance level of the device. |
|
$ref: /schemas/types.yaml#/definitions/uint32 |
|
|
|
opp-peak-kBps: |
|
description: |
|
Peak bandwidth in kilobytes per second, expressed as an array of |
|
32-bit big-endian integers. Each element of the array represents the |
|
peak bandwidth value of each interconnect path. The number of elements |
|
should match the number of interconnect paths. |
|
minItems: 1 |
|
maxItems: 32 # Should be enough |
|
|
|
opp-avg-kBps: |
|
description: |
|
Average bandwidth in kilobytes per second, expressed as an array |
|
of 32-bit big-endian integers. Each element of the array represents the |
|
average bandwidth value of each interconnect path. The number of elements |
|
should match the number of interconnect paths. This property is only |
|
meaningful in OPP tables where opp-peak-kBps is present. |
|
minItems: 1 |
|
maxItems: 32 # Should be enough |
|
|
|
clock-latency-ns: |
|
description: |
|
Specifies the maximum possible transition latency (in nanoseconds) for |
|
switching to this OPP from any other OPP. |
|
|
|
turbo-mode: |
|
description: |
|
Marks the OPP to be used only for turbo modes. Turbo mode is available |
|
on some platforms, where the device can run over its operating |
|
frequency for a short duration of time limited by the device's power, |
|
current and thermal limits. |
|
type: boolean |
|
|
|
opp-suspend: |
|
description: |
|
Marks the OPP to be used during device suspend. If multiple OPPs in |
|
the table have this, the OPP with highest opp-hz will be used. |
|
type: boolean |
|
|
|
opp-supported-hw: |
|
description: | |
|
This property allows a platform to enable only a subset of the OPPs |
|
from the larger set present in the OPP table, based on the current |
|
version of the hardware (already known to the operating system). |
|
|
|
Each block present in the array of blocks in this property, represents |
|
a sub-group of hardware versions supported by the OPP. i.e. <sub-group |
|
A>, <sub-group B>, etc. The OPP will be enabled if _any_ of these |
|
sub-groups match the hardware's version. |
|
|
|
Each sub-group is a platform defined array representing the hierarchy |
|
of hardware versions supported by the platform. For a platform with |
|
three hierarchical levels of version (X.Y.Z), this field shall look |
|
like |
|
|
|
opp-supported-hw = <X1 Y1 Z1>, <X2 Y2 Z2>, <X3 Y3 Z3>. |
|
|
|
Each level (eg. X1) in version hierarchy is represented by a 32 bit |
|
value, one bit per version and so there can be maximum 32 versions per |
|
level. Logical AND (&) operation is performed for each level with the |
|
hardware's level version and a non-zero output for _all_ the levels in |
|
a sub-group means the OPP is supported by hardware. A value of |
|
0xFFFFFFFF for each level in the sub-group will enable the OPP for all |
|
versions for the hardware. |
|
$ref: /schemas/types.yaml#/definitions/uint32-matrix |
|
maxItems: 32 |
|
items: |
|
minItems: 1 |
|
maxItems: 4 |
|
|
|
required-opps: |
|
description: |
|
This contains phandle to an OPP node in another device's OPP table. It |
|
may contain an array of phandles, where each phandle points to an OPP |
|
of a different device. It should not contain multiple phandles to the |
|
OPP nodes in the same OPP table. This specifies the minimum required |
|
OPP of the device(s), whose OPP's phandle is present in this property, |
|
for the functioning of the current device at the current OPP (where |
|
this property is present). |
|
$ref: /schemas/types.yaml#/definitions/phandle-array |
|
items: |
|
maxItems: 1 |
|
|
|
patternProperties: |
|
'^opp-microvolt-': |
|
description: |
|
Named opp-microvolt property. This is exactly similar to the above |
|
opp-microvolt property, but allows multiple voltage ranges to be |
|
provided for the same OPP. At runtime, the platform can pick a <name> |
|
and matching opp-microvolt-<name> property will be enabled for all |
|
OPPs. If the platform doesn't pick a specific <name> or the <name> |
|
doesn't match with any opp-microvolt-<name> properties, then |
|
opp-microvolt property shall be used, if present. |
|
$ref: /schemas/types.yaml#/definitions/uint32-matrix |
|
minItems: 1 |
|
maxItems: 8 # Should be enough regulators |
|
items: |
|
minItems: 1 |
|
maxItems: 3 |
|
|
|
'^opp-microamp-': |
|
description: |
|
Named opp-microamp property. Similar to opp-microvolt-<name> property, |
|
but for microamp instead. |
|
$ref: /schemas/types.yaml#/definitions/uint32-array |
|
minItems: 1 |
|
maxItems: 8 # Should be enough regulators |
|
|
|
'^opp-microwatt': |
|
description: |
|
Named opp-microwatt property. Similar to opp-microamp property, |
|
but for microwatt instead. |
|
$ref: /schemas/types.yaml#/definitions/uint32-array |
|
minItems: 1 |
|
maxItems: 8 # Should be enough regulators |
|
|
|
dependencies: |
|
opp-avg-kBps: [ opp-peak-kBps ] |
|
|
|
required: |
|
- compatible |
|
|
|
additionalProperties: true |
|
|
|
...
|
|
|