Move the ti-cpufreq binding over to opp and convert the free text
binding to json-schema.
Reviewed-by: Dhruva Gole <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
---
Changes since V2:
* Just fixup for commit message and picked up Reviewed-by from Dhruva.
V2: https://lore.kernel.org/r/[email protected]
V1: https://lore.kernel.org/all/[email protected]/
Side note: Cleanups in dt is picked up on Tony's tree:
https://lore.kernel.org/all/[email protected]/
.../bindings/cpufreq/ti-cpufreq.txt | 132 ------------------
.../opp/operating-points-v2-ti-cpu.yaml | 88 ++++++++++++
2 files changed, 88 insertions(+), 132 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
create mode 100644 Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
deleted file mode 100644
index 1758051798fe..000000000000
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-TI CPUFreq and OPP bindings
-================================
-
-Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
-families support different OPPs depending on the silicon variant in use.
-The ti-cpufreq driver can use revision and an efuse value from the SoC to
-provide the OPP framework with supported hardware information. This is
-used to determine which OPPs from the operating-points-v2 table get enabled
-when it is parsed by the OPP framework.
-
-Required properties:
---------------------
-In 'cpus' nodes:
-- operating-points-v2: Phandle to the operating-points-v2 table to use.
-
-In 'operating-points-v2' table:
-- compatible: Should be
- - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx,
- omap34xx, omap36xx and am3517 SoCs
-- syscon: A phandle pointing to a syscon node representing the control module
- register space of the SoC.
-
-Optional properties:
---------------------
-- "vdd-supply", "vbb-supply": to define two regulators for dra7xx
-- "cpu0-supply", "vbb-supply": to define two regulators for omap36xx
-
-For each opp entry in 'operating-points-v2' table:
-- opp-supported-hw: Two bitfields indicating:
- 1. Which revision of the SoC the OPP is supported by
- 2. Which eFuse bits indicate this OPP is available
-
- A bitwise AND is performed against these values and if any bit
- matches, the OPP gets enabled.
-
-Example:
---------
-
-/* From arch/arm/boot/dts/am33xx.dtsi */
-cpus {
- #address-cells = <1>;
- #size-cells = <0>;
- cpu@0 {
- compatible = "arm,cortex-a8";
- device_type = "cpu";
- reg = <0>;
-
- operating-points-v2 = <&cpu0_opp_table>;
-
- clocks = <&dpll_mpu_ck>;
- clock-names = "cpu";
-
- clock-latency = <300000>; /* From omap-cpufreq driver */
- };
-};
-
-/*
- * cpu0 has different OPPs depending on SoC revision and some on revisions
- * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
- */
-cpu0_opp_table: opp-table {
- compatible = "operating-points-v2-ti-cpu";
- syscon = <&scm_conf>;
-
- /*
- * The three following nodes are marked with opp-suspend
- * because they can not be enabled simultaneously on a
- * single SoC.
- */
- opp50-300000000 {
- opp-hz = /bits/ 64 <300000000>;
- opp-microvolt = <950000 931000 969000>;
- opp-supported-hw = <0x06 0x0010>;
- opp-suspend;
- };
-
- opp100-275000000 {
- opp-hz = /bits/ 64 <275000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x01 0x00FF>;
- opp-suspend;
- };
-
- opp100-300000000 {
- opp-hz = /bits/ 64 <300000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x06 0x0020>;
- opp-suspend;
- };
-
- opp100-500000000 {
- opp-hz = /bits/ 64 <500000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- opp100-600000000 {
- opp-hz = /bits/ 64 <600000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x06 0x0040>;
- };
-
- opp120-600000000 {
- opp-hz = /bits/ 64 <600000000>;
- opp-microvolt = <1200000 1176000 1224000>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- opp120-720000000 {
- opp-hz = /bits/ 64 <720000000>;
- opp-microvolt = <1200000 1176000 1224000>;
- opp-supported-hw = <0x06 0x0080>;
- };
-
- oppturbo-720000000 {
- opp-hz = /bits/ 64 <720000000>;
- opp-microvolt = <1260000 1234800 1285200>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- oppturbo-800000000 {
- opp-hz = /bits/ 64 <800000000>;
- opp-microvolt = <1260000 1234800 1285200>;
- opp-supported-hw = <0x06 0x0100>;
- };
-
- oppnitro-1000000000 {
- opp-hz = /bits/ 64 <1000000000>;
- opp-microvolt = <1325000 1298500 1351500>;
- opp-supported-hw = <0x04 0x0200>;
- };
-};
diff --git a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
new file mode 100644
index 000000000000..ada57bfc1da9
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
@@ -0,0 +1,88 @@
+# 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:
+ Certain TI SoCs, like those in the am335x, am437x, am57xx, am62x and dra7xx
+ families support different OPPs depending on the silicon variant in use.
+ The ti-cpufreq driver can use revision and an efuse value from the SoC to
+ provide the OPP framework with supported hardware information. This is
+ used to determine which OPPs from the operating-points-v2 table get enabled
+ when it is parsed by the OPP framework.
+
+maintainers:
+ - Nishanth Menon <[email protected]>
+
+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: true
+ 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>;
+ };
+ };
--
2.40.0
On Aug 08, 2023 at 21:30:45 -0500, Nishanth Menon wrote:
> Move the ti-cpufreq binding over to opp and convert the free text
> binding to json-schema.
>
> Reviewed-by: Dhruva Gole <[email protected]>
> Signed-off-by: Nishanth Menon <[email protected]>
> ---
> Changes since V2:
> * Just fixup for commit message and picked up Reviewed-by from Dhruva.
>
> V2: https://lore.kernel.org/r/[email protected]
> V1: https://lore.kernel.org/all/[email protected]/
>
> Side note: Cleanups in dt is picked up on Tony's tree:
> https://lore.kernel.org/all/[email protected]/
>
> .../bindings/cpufreq/ti-cpufreq.txt | 132 ------------------
> .../opp/operating-points-v2-ti-cpu.yaml | 88 ++++++++++++
> 2 files changed, 88 insertions(+), 132 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> create mode 100644 Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
>
[...]
> new file mode 100644
> index 000000000000..ada57bfc1da9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
> @@ -0,0 +1,88 @@
> +# 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:
> + Certain TI SoCs, like those in the am335x, am437x, am57xx, am62x and dra7xx
> + families support different OPPs depending on the silicon variant in use.
> + The ti-cpufreq driver can use revision and an efuse value from the SoC to
Just learned about this yesterday, hence missed it in my earlier review.
Looks like the kernel docs [0] say that we DON'T refer to Linux or
"device driver" in bindings.
Bindings should be based on what the hardware has, not what an OS and
driver currently support.
> + provide the OPP framework with supported hardware information. This is
> + used to determine which OPPs from the operating-points-v2 table get enabled
> + when it is parsed by the OPP framework.
> +
[...]
[0] https://docs.kernel.org/devicetree/bindings/writing-bindings.html
--
Best regards,
Dhruva Gole <[email protected]>
On 10:00-20230809, Dhruva Gole wrote:
[..]
> > +description:
> > + Certain TI SoCs, like those in the am335x, am437x, am57xx, am62x and dra7xx
> > + families support different OPPs depending on the silicon variant in use.
> > + The ti-cpufreq driver can use revision and an efuse value from the SoC to
>
> Just learned about this yesterday, hence missed it in my earlier review.
> Looks like the kernel docs [0] say that we DON'T refer to Linux or
> "device driver" in bindings.
>
> Bindings should be based on what the hardware has, not what an OS and
> driver currently support.
Thanks for catching this. will fix in the next rev.
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D