Add the device tree bindings document for the TI CPUFreq/OPP driver
on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us
to provide an opp-supported-hw property for each OPP to define when
it is available. This driver is responsible for reading and parsing
registers to determine which OPPs can be selectively enabled based
on the specific SoC in use by matching against the opp-supported-hw
data.
Signed-off-by: Dave Gerlach <d-gerlach@xxxxxx>
---
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 89 ++++++++++++++++++++++
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
new file mode 100644
index 000000000000..f719b2df2a1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -0,0 +1,89 @@
+Bindings for TI's CPUFreq driver
+================================
+
+The ti-cpufreq driver works with the operating-points-v2 binding described
+at [../opp/opp.txt] to make sure the proper OPPs for a platform get enabled
+and then creates a "cpufreq-dt" platform device to leverage the cpufreq-dt
+driver described in [cpufreq-dt.txt].
+
+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 uses the 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. In
+order to maintain backwards compatilibity if this information is not present
+the "cpufreq-dt" platform device is still created to attempt to find an
+operating-points (v1) table, otherwise no OPPs will be available because
+safe OPPs cannot be determined.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use
+- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
+ mask, and efuse register shift to get the relevant bits
+ that describe OPP availability
+- ti,syscon-rev: Syscon and offset used to look up revision value on SoC
+
+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.
+
+NOTE: Without the above, platform-device for "cpufreq-dt" is still created
+ but no determination of which OPPs should be available is done, but this
+ allows for use of a v1 operating-points table.
+
+Example:
+--------
+
+/* From arch/arm/boot/dts/am4372.dtsi */
+cpus {
+ cpu: cpu@0 {
+ ...
+
+ operating-points-v2 = <&cpu0_opp_table>;
+
+ ti,syscon-efuse = <&scm_conf 0x610 0x3f 0>;
+ ti,syscon-rev = <&scm_conf 0x600>;
+
+ ...
+ };
+};
+
+cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp50@300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <950000>;
+ opp-supported-hw = <0xFF 0x01>;
+ opp-suspend;
+ };
+
+ opp100@600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1100000>;
+ opp-supported-hw = <0xFF 0x04>;
+ };
+
+ opp120@720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <1200000>;
+ opp-supported-hw = <0xFF 0x08>;
+ };
+
+ oppturbo@800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <1260000>;
+ opp-supported-hw = <0xFF 0x10>;
+ };
+
+ oppnitro@1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1325000>;
+ opp-supported-hw = <0xFF 0x20>;
+ };
+};
--
2.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
