lastdragon/linux-kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resguardo inicial

Browse Source
This commit is contained in:
lastdragon
2026-09-06 12:53:21 -06:00
parent 662efe3c2a
commit ad2088d178
94853 changed files with 43200404 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
linux-7.2.3/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
+135
View File
@@ -0,0 +1,135 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/allwinner,sun50i-h6-operating-points.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner H6 CPU OPP
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
description: |
For some SoCs, the CPU frequency subset and voltage value of each
OPP varies based on the silicon variant in use. Allwinner Process
Voltage Scaling Tables define the voltage and frequency values based
on the speedbin blown in the efuse combination.
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
enum:
- allwinner,sun50i-a100-operating-points
- allwinner,sun50i-h6-operating-points
- allwinner,sun50i-h616-operating-points
nvmem-cells:
description: |
A phandle pointing to a nvmem-cells node representing the efuse
register that has information about the speedbin that is used
to select the right frequency/voltage value pair. Please refer
to the nvmem-cells bindings in
Documentation/devicetree/bindings/nvmem/nvmem.yaml and also the
examples below.
opp-shared: true
required:
- compatible
- nvmem-cells
patternProperties:
"^opp-[0-9]+$":
type: object
properties:
opp-hz: true
clock-latency-ns: true
opp-microvolt: true
opp-supported-hw:
maxItems: 1
description:
A single 32 bit bitmap value, representing compatible HW, one
bit per speed bin index.
patternProperties:
"^opp-microvolt-speed[0-9]$": true
required:
- opp-hz
unevaluatedProperties: false
additionalProperties: false
examples:
- |
cpu_opp_table: opp-table {
compatible = "allwinner,sun50i-h6-operating-points";
nvmem-cells = <&speedbin_efuse>;
opp-shared;
opp-480000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <480000000>;
opp-microvolt-speed0 = <880000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp-1080000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1080000000>;
opp-microvolt-speed0 = <1060000>;
opp-microvolt-speed1 = <880000>;
opp-microvolt-speed2 = <840000>;
};
opp-1488000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1488000000>;
opp-microvolt-speed0 = <1160000>;
opp-microvolt-speed1 = <1000000>;
opp-microvolt-speed2 = <960000>;
};
};
- |
opp-table {
compatible = "allwinner,sun50i-h616-operating-points";
nvmem-cells = <&speedbin_efuse>;
opp-shared;
opp-480000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <480000000>;
opp-microvolt = <900000>;
opp-supported-hw = <0x1f>;
};
opp-792000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <792000000>;
opp-microvolt-speed1 = <900000>;
opp-microvolt-speed4 = <940000>;
opp-supported-hw = <0x12>;
};
opp-1512000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1512000000>;
opp-microvolt = <1100000>;
opp-supported-hw = <0x0a>;
};
};
...
linux-7.2.3/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
+110
View File
@@ -0,0 +1,110 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/operating-points-v2-ti-cpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI CPU OPP (Operating Performance Points)
description:
TI SoCs, like those in the AM335x, AM437x, AM57xx, AM62x, and DRA7xx
families, the CPU frequencies subset and the voltage value of each
OPP vary based on the silicon variant used. The data sheet sections
corresponding to "Operating Performance Points" describe the frequency
and voltage values based on device type and speed bin information
blown in corresponding eFuse bits as referred to by the Technical
Reference Manual.
This document extends the operating-points-v2 binding by providing
the hardware description for the scheme mentioned above.
maintainers:
- Dhruva Gole <d-gole@ti.com>
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
const: operating-points-v2-ti-cpu
syscon:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
points to syscon node representing the control module
register space of the SoC.
opp-shared: true
patternProperties:
'^opp(-?[0-9]+)*$':
type: object
additionalProperties: false
properties:
clock-latency-ns: true
opp-hz: true
opp-microvolt: true
opp-supported-hw:
items:
items:
- description:
The revision of the SoC the OPP is supported by.
This can be easily obtained from the datasheet of the
part being ordered/used. For example, it will be 0x01 for SR1.0
- description:
The eFuse bits that indicate the particular OPP is available.
The device datasheet has a table talking about Device Speed Grades.
This table is to be sorted with only the unique elements of the
MAXIMUM OPERATING FREQUENCY starting from the first row which
tells the lowest OPP, to the highest. The corresponding bits
need to be set based on N elements of speed grade the device supports.
So, if there are 3 possible unique MAXIMUM OPERATING FREQUENCY
in the table, then BIT(0) | (1) | (2) will be set, which means
the value shall be 0x7.
opp-suspend: true
turbo-mode: true
required:
- opp-hz
- opp-supported-hw
required:
- compatible
- syscon
additionalProperties: false
examples:
- |
opp-table {
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0xFFFF>;
};
opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0x04 0x0200>;
};
};
linux-7.2.3/Documentation/devicetree/bindings/opp/opp-v1.yaml
+67
View File
@@ -0,0 +1,67 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/opp-v1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic OPP (Operating Performance Points) v1
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
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 binding only supports voltage-frequency pairs.
deprecated: true
properties:
clock-latency:
$ref: /schemas/types.yaml#/definitions/uint32
description:
The latency in nanoseconds for clock changes. Use OPP tables for new
designs instead.
voltage-tolerance:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 10
description:
The voltage tolerance in percent. Use OPP tables for new designs instead.
operating-points:
$ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
items:
- description: Frequency in kHz
- description: Voltage for OPP in uV
dependencies:
clock-latency: [ operating-points ]
voltage-tolerance: [ operating-points ]
additionalProperties: true
examples:
- |
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
operating-points =
/* kHz uV */
<792000 1100000>,
<396000 950000>,
<198000 850000>;
};
};
...
linux-7.2.3/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
+247
View File
@@ -0,0 +1,247 @@
# 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 Properties
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
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: 32
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 power 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-<name> 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
...
linux-7.2.3/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
+309
View File
@@ -0,0 +1,309 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/opp-v2-kryo-cpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies, Inc. NVMEM OPP
maintainers:
- Ilia Lin <ilia.lin@kernel.org>
allOf:
- $ref: opp-v2-base.yaml#
description: |
In certain Qualcomm Technologies, Inc. SoCs like APQ8096 and MSM8996,
the CPU frequencies subset and voltage value of each OPP varies based on
the silicon variant in use.
Qualcomm Technologies, Inc. Process Voltage Scaling Tables
defines the voltage and frequency value based on the speedbin blown in
the efuse combination.
The qcom-cpufreq-nvmem driver reads the efuse value from the SoC to provide
the OPP framework with required information (existing HW bitmap).
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
properties:
compatible:
enum:
- operating-points-v2-krait-cpu
- operating-points-v2-kryo-cpu
nvmem-cells:
description: |
A phandle pointing to a nvmem-cells node representing the
efuse registers that has information about the
speedbin that is used to select the right frequency/voltage
value pair.
opp-shared: true
patternProperties:
'^opp-?[0-9]+$':
type: object
additionalProperties: false
properties:
opp-hz: true
opp-microvolt: true
opp-peak-kBps: true
opp-supported-hw:
description: |
A single 32 bit bitmap value, representing compatible HW.
Bitmap for MSM8996 format:
0: MSM8996, speedbin 0
1: MSM8996, speedbin 1
2: MSM8996, speedbin 2
3: MSM8996, speedbin 3
4-31: unused
Bitmap for MSM8996SG format (speedbin shifted of 4 left):
0-3: unused
4: MSM8996SG, speedbin 0
5: MSM8996SG, speedbin 1
6: MSM8996SG, speedbin 2
7-31: unused
Bitmap for IPQ806x SoC:
0: IPQ8062
1: IPQ8064/IPQ8066/IPQ8068
2: IPQ8065/IPQ8069
3-31: unused
Other platforms use bits directly corresponding to speedbin index.
clock-latency-ns: true
required-opps: true
patternProperties:
'^opp-microvolt-speed[0-9]+-pvs[0-9]+$': true
required:
- opp-hz
required:
- compatible
if:
required:
- nvmem-cells
then:
patternProperties:
'^opp-?[0-9]+$':
required:
- opp-supported-hw
additionalProperties: false
examples:
- |
/ {
model = "Qualcomm Technologies, Inc. DB820c";
compatible = "arrow,apq8096-db820c", "qcom,apq8096-sbc", "qcom,apq8096";
#address-cells = <2>;
#size-cells = <2>;
cpus {
#address-cells = <2>;
#size-cells = <0>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "qcom,kryo";
reg = <0x0 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
capacity-dmips-mhz = <1024>;
clocks = <&kryocc 0>;
operating-points-v2 = <&cluster0_opp>;
power-domains = <&cpr>;
power-domain-names = "cpr";
#cooling-cells = <2>;
next-level-cache = <&L2_0>;
L2_0: l2-cache {
compatible = "cache";
cache-level = <2>;
cache-unified;
};
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "qcom,kryo";
reg = <0x0 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
capacity-dmips-mhz = <1024>;
clocks = <&kryocc 0>;
operating-points-v2 = <&cluster0_opp>;
power-domains = <&cpr>;
power-domain-names = "cpr";
#cooling-cells = <2>;
next-level-cache = <&L2_0>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "qcom,kryo";
reg = <0x0 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
capacity-dmips-mhz = <1024>;
clocks = <&kryocc 1>;
operating-points-v2 = <&cluster1_opp>;
power-domains = <&cpr>;
power-domain-names = "cpr";
#cooling-cells = <2>;
next-level-cache = <&L2_1>;
L2_1: l2-cache {
compatible = "cache";
cache-level = <2>;
cache-unified;
};
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "qcom,kryo";
reg = <0x0 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
capacity-dmips-mhz = <1024>;
clocks = <&kryocc 1>;
operating-points-v2 = <&cluster1_opp>;
power-domains = <&cpr>;
power-domain-names = "cpr";
#cooling-cells = <2>;
next-level-cache = <&L2_1>;
};
cpu-map {
cluster0 {
core0 {
cpu = <&CPU0>;
};
core1 {
cpu = <&CPU1>;
};
};
cluster1 {
core0 {
cpu = <&CPU2>;
};
core1 {
cpu = <&CPU3>;
};
};
};
};
cluster0_opp: opp-table-0 {
compatible = "operating-points-v2-kryo-cpu";
nvmem-cells = <&speedbin_efuse>;
opp-shared;
opp-307200000 {
opp-hz = /bits/ 64 <307200000>;
opp-microvolt = <905000 905000 1140000>;
opp-supported-hw = <0x7>;
clock-latency-ns = <200000>;
required-opps = <&cpr_opp1>;
};
opp-1401600000 {
opp-hz = /bits/ 64 <1401600000>;
opp-microvolt = <1140000 905000 1140000>;
opp-supported-hw = <0x5>;
clock-latency-ns = <200000>;
required-opps = <&cpr_opp2>;
};
opp-1593600000 {
opp-hz = /bits/ 64 <1593600000>;
opp-microvolt = <1140000 905000 1140000>;
opp-supported-hw = <0x1>;
clock-latency-ns = <200000>;
required-opps = <&cpr_opp3>;
};
};
cluster1_opp: opp-table-1 {
compatible = "operating-points-v2-kryo-cpu";
nvmem-cells = <&speedbin_efuse>;
opp-shared;
opp-307200000 {
opp-hz = /bits/ 64 <307200000>;
opp-microvolt = <905000 905000 1140000>;
opp-supported-hw = <0x7>;
clock-latency-ns = <200000>;
required-opps = <&cpr_opp1>;
};
opp-1804800000 {
opp-hz = /bits/ 64 <1804800000>;
opp-microvolt = <1140000 905000 1140000>;
opp-supported-hw = <0x6>;
clock-latency-ns = <200000>;
required-opps = <&cpr_opp4>;
};
opp-1900800000 {
opp-hz = /bits/ 64 <1900800000>;
opp-microvolt = <1140000 905000 1140000>;
opp-supported-hw = <0x4>;
clock-latency-ns = <200000>;
required-opps = <&cpr_opp5>;
};
opp-2150400000 {
opp-hz = /bits/ 64 <2150400000>;
opp-microvolt = <1140000 905000 1140000>;
opp-supported-hw = <0x1>;
clock-latency-ns = <200000>;
required-opps = <&cpr_opp6>;
};
};
/* Dummy opp table to give example for named opp-microvolt */
opp-table-2 {
compatible = "operating-points-v2-krait-cpu";
nvmem-cells = <&speedbin_efuse>;
opp-384000000 {
opp-hz = /bits/ 64 <384000000>;
opp-microvolt-speed0-pvs0 = <1000000 950000 1050000>;
opp-microvolt-speed0-pvs1 = <925000 878750 971250>;
opp-microvolt-speed0-pvs2 = <875000 831250 918750>;
opp-microvolt-speed0-pvs3 = <800000 760000 840000>;
opp-supported-hw = <0x7>;
clock-latency-ns = <100000>;
};
};
smem {
compatible = "qcom,smem";
memory-region = <&smem_mem>;
hwlocks = <&tcsr_mutex 3>;
};
soc {
#address-cells = <1>;
#size-cells = <1>;
qfprom: qfprom@74000 {
compatible = "qcom,msm8996-qfprom", "qcom,qfprom";
reg = <0x00074000 0x8ff>;
#address-cells = <1>;
#size-cells = <1>;
speedbin_efuse: speedbin@133 {
reg = <0x133 0x1>;
bits = <5 3>;
};
};
};
};
linux-7.2.3/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml
+96
View File
@@ -0,0 +1,96 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/opp-v2-qcom-adreno.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Adreno compatible OPP supply
description:
Adreno GPUs present in Qualcomm's Snapdragon chipsets uses an OPP specific
ACD related information tailored for the specific chipset. This binding
provides the information needed to describe such a hardware value.
maintainers:
- Rob Clark <robdclark@gmail.com>
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
contains:
const: operating-points-v2-adreno
patternProperties:
'^opp(-[0-9]+){1,2}$':
type: object
additionalProperties: false
properties:
opp-hz: true
opp-level: true
opp-peak-kBps: true
opp-supported-hw: true
qcom,opp-acd-level:
description: |
A positive value representing the ACD (Adaptive Clock Distribution,
a fancy name for clk throttling during voltage droop) level associated
with this OPP node. This value is shared to a co-processor inside GPU
(called Graphics Management Unit a.k.a GMU) during wake up. It may not
be present for some OPPs and GMU will disable ACD while transitioning
to that OPP. This value encodes a voltage threshold, delay cycles &
calibration margins which are identified by characterization of the
SoC. So, it doesn't have any unit. This data is passed to GMU firmware
via 'HFI_H2F_MSG_ACD' packet.
$ref: /schemas/types.yaml#/definitions/uint32
required:
- opp-hz
- opp-level
required:
- compatible
additionalProperties: false
examples:
- |
#include <dt-bindings/power/qcom-rpmpd.h>
gpu_opp_table: opp-table {
compatible = "operating-points-v2-adreno", "operating-points-v2";
opp-687000000 {
opp-hz = /bits/ 64 <687000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
opp-peak-kBps = <8171875>;
qcom,opp-acd-level = <0x882e5ffd>;
};
opp-550000000 {
opp-hz = /bits/ 64 <550000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
opp-peak-kBps = <6074219>;
qcom,opp-acd-level = <0xc0285ffd>;
};
opp-390000000 {
opp-hz = /bits/ 64 <390000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
opp-peak-kBps = <3000000>;
qcom,opp-acd-level = <0xc0285ffd>;
};
opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
opp-peak-kBps = <2136719>;
/* Intentionally left out qcom,opp-acd-level property here */
};
};
linux-7.2.3/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml
+63
View File
@@ -0,0 +1,63 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/opp-v2-qcom-level.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm OPP
maintainers:
- Niklas Cassel <nks@flawful.org>
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
const: operating-points-v2-qcom-level
patternProperties:
'^opp-?[0-9]+$':
type: object
additionalProperties: false
properties:
opp-level: true
qcom,opp-fuse-level:
description: |
A positive value representing the fuse corner/level associated with
this OPP node. Sometimes several corners/levels shares a certain fuse
corner/level. A fuse corner/level contains e.g. ref uV, min uV,
and max uV.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 2
required:
- opp-level
- qcom,opp-fuse-level
required:
- compatible
additionalProperties: false
examples:
- |
cpr_opp_table: opp-table-cpr {
compatible = "operating-points-v2-qcom-level";
cpr_opp1: opp1 {
opp-level = <1>;
qcom,opp-fuse-level = <1>;
};
cpr_opp2: opp2 {
opp-level = <2>;
qcom,opp-fuse-level = <2>;
};
cpr_opp3: opp3 {
opp-level = <3>;
qcom,opp-fuse-level = <3>;
};
};
linux-7.2.3/Documentation/devicetree/bindings/opp/opp-v2.yaml
+475
View File
@@ -0,0 +1,475 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/opp-v2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic OPP (Operating Performance Points)
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
const: operating-points-v2
unevaluatedProperties: false
examples:
- |
/*
* Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states
* together.
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu0_opp_table0>;
};
cpu@1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu0_opp_table0>;
};
};
cpu0_opp_table0: opp-table {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <290000>;
turbo-mode;
};
};
- |
/*
* Example 2: Single cluster, Quad-core Qualcom-krait, switches DVFS states
* independently.
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "qcom,krait";
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@1 {
compatible = "qcom,krait";
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@2 {
compatible = "qcom,krait";
device_type = "cpu";
reg = <2>;
next-level-cache = <&L2>;
clocks = <&clk_controller 2>;
clock-names = "cpu";
cpu-supply = <&cpu_supply2>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@3 {
compatible = "qcom,krait";
device_type = "cpu";
reg = <3>;
next-level-cache = <&L2>;
clocks = <&clk_controller 3>;
clock-names = "cpu";
cpu-supply = <&cpu_supply3>;
operating-points-v2 = <&cpu_opp_table>;
};
};
cpu_opp_table: opp-table {
compatible = "operating-points-v2";
/*
* Missing opp-shared property means CPUs switch DVFS states
* independently.
*/
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
clock-latency-ns = <290000>;
turbo-mode;
};
};
- |
/*
* Example 3: Dual-cluster, Dual-core per cluster. CPUs within a cluster switch
* DVFS state together.
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0x0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cluster0_opp>;
};
cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0x1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cluster0_opp>;
};
cpu@100 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <0x100>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cluster1_opp>;
};
cpu@101 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <0x101>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cluster1_opp>;
};
};
cluster0_opp: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
clock-latency-ns = <290000>;
turbo-mode;
};
};
cluster1_opp: opp-table-1 {
compatible = "operating-points-v2";
opp-shared;
opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1050000 1045000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
opp-suspend;
};
opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1075000>;
opp-microamp = <100000>;
clock-latency-ns = <400000>;
};
opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1100000 1010000 1110000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
turbo-mode;
};
};
- |
/* Example 4: Handling multiple regulators */
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "foo,cpu-type";
device_type = "cpu";
reg = <0>;
vcc0-supply = <&cpu_supply0>;
vcc1-supply = <&cpu_supply1>;
vcc2-supply = <&cpu_supply2>;
operating-points-v2 = <&cpu0_opp_table4>;
};
};
cpu0_opp_table4: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
<960000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<70000>, /* Supply 1 */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
/* OR */
opp-1000000001 {
opp-hz = /bits/ 64 <1000000001>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
<965000 960000 975000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<70000>, /* Supply 1 */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
/* OR */
opp-1000000002 {
opp-hz = /bits/ 64 <1000000002>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
<965000 960000 975000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<0>, /* Supply 1 doesn't need this */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
};
- |
/*
* Example 5: opp-supported-hw
* (example: three level hierarchy of versions: cuts, substrate and process)
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
cpu-supply = <&cpu_supply>;
operating-points-v2 = <&cpu0_opp_table_slow>;
};
};
cpu0_opp_table_slow: opp-table {
compatible = "operating-points-v2";
opp-shared;
opp-600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
*/
opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF>;
opp-hz = /bits/ 64 <600000000>;
};
opp-800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
* - substrate: supports 16 different substrate versions
* - process: supports 9 different process versions
*/
opp-supported-hw = <0x20 0xff0000ff 0x0000f4f0>;
opp-hz = /bits/ 64 <800000000>;
};
opp-900000000 {
/*
* Supports:
* - All cuts and substrate where process version is 0x2.
* - All cuts and process where substrate version is 0x2.
*/
opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0x02>,
<0xFFFFFFFF 0x01 0xFFFFFFFF>;
opp-hz = /bits/ 64 <900000000>;
};
};
- |
/*
* Example 6: opp-microvolt-<name>, opp-microamp-<name>:
* (example: device with two possible microvolt ranges: slow and fast)
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
operating-points-v2 = <&cpu0_opp_table6>;
};
};
cpu0_opp_table6: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt-slow = <915000 900000 925000>;
opp-microvolt-fast = <975000 970000 985000>;
opp-microamp-slow = <70000>;
opp-microamp-fast = <71000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt-slow = <915000 900000 925000>, /* Supply vcc0 */
<925000 910000 935000>; /* Supply vcc1 */
opp-microvolt-fast = <975000 970000 985000>, /* Supply vcc0 */
<965000 960000 975000>; /* Supply vcc1 */
opp-microamp = <70000>; /* Will be used for both slow/fast */
};
};
- |
/*
* Example 7: Single cluster Quad-core ARM cortex A53, OPP points from firmware,
* distinct clock controls but two sets of clock/voltage/current lines.
*/
cpus {
#address-cells = <2>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x0 0x100>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 0>;
operating-points-v2 = <&cpu_opp0_table>;
};
cpu@1 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x0 0x101>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 1>;
operating-points-v2 = <&cpu_opp0_table>;
};
cpu@2 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x0 0x102>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 2>;
operating-points-v2 = <&cpu_opp1_table>;
};
cpu@3 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x0 0x103>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 3>;
operating-points-v2 = <&cpu_opp1_table>;
};
};
cpu_opp0_table: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
};
cpu_opp1_table: opp-table-1 {
compatible = "operating-points-v2";
opp-shared;
};
...
linux-7.2.3/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml
+101
View File
@@ -0,0 +1,101 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/ti,omap-opp-supply.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments OMAP compatible OPP supply
description:
OMAP5, DRA7, and AM57 families of SoCs have Class 0 AVS eFuse
registers, which contain OPP-specific voltage information tailored
for the specific device. This binding provides the information
needed to describe such a hardware values and relate them to program
the primary regulator during an OPP transition.
Also, some supplies may have an associated vbb-supply, an Adaptive
Body Bias regulator, which must transition in a specific sequence
w.r.t the vdd-supply and clk when making an OPP transition. By
supplying two regulators to the device that will undergo OPP
transitions, we can use the multi-regulator support implemented by
the OPP core to describe both regulators the platform needs. The
OPP core binding Documentation/devicetree/bindings/opp/opp-v2.yaml
provides further information (refer to Example 4 Handling multiple
regulators).
maintainers:
- Nishanth Menon <nm@ti.com>
properties:
$nodename:
pattern: '^opp-supply(@[0-9a-f]+)?$'
compatible:
oneOf:
- description: Basic OPP supply controlling VDD and VBB
const: ti,omap-opp-supply
- description: OMAP5+ optimized voltages in efuse(Class 0) VDD along with
VBB.
const: ti,omap5-opp-supply
- description: OMAP5+ optimized voltages in efuse(class0) VDD but no VBB
const: ti,omap5-core-opp-supply
reg:
maxItems: 1
ti,absolute-max-voltage-uv:
$ref: /schemas/types.yaml#/definitions/uint32
description: Absolute maximum voltage for the OPP supply in micro-volts.
minimum: 750000
maximum: 1500000
ti,efuse-settings:
description: An array of u32 tuple items providing information about
optimized efuse configuration.
minItems: 1
$ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
items:
- description: Reference voltage in micro-volts (OPP Voltage)
minimum: 750000
maximum: 1500000
multipleOf: 10000
- description: efuse offset where the optimized voltage is located
multipleOf: 4
maximum: 256
required:
- compatible
- ti,absolute-max-voltage-uv
allOf:
- if:
not:
properties:
compatible:
contains:
const: ti,omap-opp-supply
then:
required:
- reg
- ti,efuse-settings
additionalProperties: false
examples:
- |
opp-supply {
compatible = "ti,omap-opp-supply";
ti,absolute-max-voltage-uv = <1375000>;
};
- |
opp-supply@4a003b20 {
compatible = "ti,omap5-opp-supply";
reg = <0x4a003b20 0x8>;
ti,efuse-settings =
/* uV offset */
<1060000 0x0>,
<1160000 0x4>,
<1210000 0x8>;
ti,absolute-max-voltage-uv = <1500000>;
};