[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180731161340.13000-3-georgi.djakov@linaro.org>
Date: Tue, 31 Jul 2018 19:13:34 +0300
From: Georgi Djakov <georgi.djakov@...aro.org>
To: linux-pm@...r.kernel.org, gregkh@...uxfoundation.org
Cc: rjw@...ysocki.net, robh+dt@...nel.org, mturquette@...libre.com,
khilman@...libre.com, vincent.guittot@...aro.org,
skannan@...eaurora.org, bjorn.andersson@...aro.org,
amit.kucheria@...aro.org, seansw@....qualcomm.com,
daidavid1@...eaurora.org, evgreen@...omium.org,
mark.rutland@....com, lorenzo.pieralisi@....com,
abailon@...libre.com, arnd@...db.de, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, georgi.djakov@...aro.org
Subject: [PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings
This binding is intended to represent the interconnect hardware present
in some of the modern SoCs. Currently it consists only of a binding for
the interconnect hardware devices (provider).
Signed-off-by: Georgi Djakov <georgi.djakov@...aro.org>
---
.../bindings/interconnect/interconnect.txt | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interconnect/interconnect.txt
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
new file mode 100644
index 000000000000..6e2b2971b094
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -0,0 +1,33 @@
+Interconnect Provider Device Tree Bindings
+=========================================
+
+The purpose of this document is to define a common set of generic interconnect
+providers/consumers properties.
+
+
+= interconnect providers =
+
+The interconnect provider binding is intended to represent the interconnect
+controllers in the system. Each provider registers a set of interconnect
+nodes, which expose the interconnect related capabilities of the interconnect
+to consumer drivers. These capabilities can be throughput, latency, priority
+etc. The consumer drivers set constraints on interconnect path (or endpoints)
+depending on the use case. Interconnect providers can also be interconnect
+consumers, such as in the case where two network-on-chip fabrics interface
+directly
+
+Required properties:
+- compatible : contains the interconnect provider compatible string
+- #interconnect-cells : number of cells in a interconnect specifier needed to
+ encode the interconnect node id
+
+Example:
+
+ snoc: snoc@...000 {
+ compatible = "qcom,msm8916-snoc";
+ #interconnect-cells = <1>;
+ reg = <0x580000 0x14000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
+ <&rpmcc RPM_SMD_SNOC_A_CLK>;
+ };
Powered by blists - more mailing lists