[PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings
From: robh@kernel.org (Rob Herring)
Date: 2018-08-02 21:02:33
Also in:
linux-arm-msm, linux-pm, lkml
On Tue, Jul 31, 2018 at 10:13 AM Georgi Djakov [off-list ref] wrote:
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).
If you want the bindings reviewed, then you need to send them to the DT list. CC'ing me is pointless, I get CC'ed too many things to read. The consumer and producer binding should be a single patch. One is not useful without the other. There is also a patch series from Maxime Ripard that's addressing the same general area. See "dt-bindings: Add a dma-parent property". We don't need multiple ways to address describing the device to memory paths, so you all had better work out a common solution. Rob
quoted hunk ↗ jump to hunk
Signed-off-by: Georgi Djakov <redacted> --- .../bindings/interconnect/interconnect.txt | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/interconnect/interconnect.txtdiff --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 at 580000 { + 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>; + };