diff options
Diffstat (limited to 'Documentation/devicetree/bindings/bus')
21 files changed, 1791 insertions, 0 deletions
diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml new file mode 100644 index 000000000..0503651cd --- /dev/null +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/allwinner,sun50i-a64-de2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A64 Display Engine Bus Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + - Maxime Ripard <mripard@kernel.org> + +properties: + $nodename: + pattern: "^bus(@[0-9a-f]+)?$" + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + compatible: + oneOf: + - const: allwinner,sun50i-a64-de2 + - items: + - const: allwinner,sun50i-h6-de3 + - const: allwinner,sun50i-a64-de2 + + reg: + maxItems: 1 + + allwinner,sram: + description: + The SRAM that needs to be claimed to access the display engine + bus. + $ref: /schemas/types.yaml#definitions/phandle-array + maxItems: 1 + + ranges: true + +patternProperties: + # All other properties should be child nodes with unit-address and 'reg' + "^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+$": + type: object + properties: + reg: + maxItems: 1 + + required: + - reg + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + - allwinner,sram + +additionalProperties: false + +examples: + - | + bus@1000000 { + compatible = "allwinner,sun50i-a64-de2"; + reg = <0x1000000 0x400000>; + allwinner,sram = <&de2_sram 1>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x1000000 0x400000>; + + display_clocks: clock@0 { + compatible = "allwinner,sun50i-a64-de2-clk"; + reg = <0x0 0x100000>; + clocks = <&ccu 52>, <&ccu 99>; + clock-names = "bus", "mod"; + resets = <&ccu 30>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml new file mode 100644 index 000000000..32d33b983 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/allwinner,sun8i-a23-rsb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A23 RSB Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + - Maxime Ripard <mripard@kernel.org> + +properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + compatible: + oneOf: + - const: allwinner,sun8i-a23-rsb + - items: + - const: allwinner,sun8i-a83t-rsb + - const: allwinner,sun8i-a23-rsb + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + clock-frequency: + minimum: 1 + maximum: 20000000 + +patternProperties: + "^.*@[0-9a-fA-F]+$": + type: object + properties: + reg: + maxItems: 1 + + required: + - reg + +required: + - compatible + - reg + - interrupts + - clocks + - resets + +examples: + - | + rsb@1f03400 { + compatible = "allwinner,sun8i-a23-rsb"; + reg = <0x01f03400 0x400>; + interrupts = <0 39 4>; + clocks = <&apb0_gates 3>; + clock-frequency = <3000000>; + resets = <&apb0_rst 3>; + #address-cells = <1>; + #size-cells = <0>; + + pmic@3e3 { + reg = <0x3e3>; + + /* ... */ + }; + }; + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/bus/arm,integrator-ap-lm.yaml b/Documentation/devicetree/bindings/bus/arm,integrator-ap-lm.yaml new file mode 100644 index 000000000..47227427c --- /dev/null +++ b/Documentation/devicetree/bindings/bus/arm,integrator-ap-lm.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/arm,integrator-ap-lm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Integrator/AP Logic Module extension bus + +maintainers: + - Linus Walleij <linusw@kernel.org> + +description: The Integrator/AP is a prototyping platform and as such has a + site for stacking up to four logic modules (LM) designed specifically for + use with this platform. A special system controller register can be read to + determine if a logic module is connected at index 0, 1, 2 or 3. The logic + module connector is described in this binding. The logic modules per se + then have their own specific per-module bindings and they will be described + as subnodes under this logic module extension bus. + +properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + compatible: + items: + - const: arm,integrator-ap-lm + + ranges: true + dma-ranges: true + +patternProperties: + "^bus(@[0-9a-f]*)?$": + description: Nodes on the Logic Module bus represent logic modules + and are named with bus. The first module is at 0xc0000000, the second + at 0xd0000000 and so on until the top of the memory of the system at + 0xffffffff. All information about the memory used by the module is + in ranges and dma-ranges. + type: object + + required: + - compatible + +required: + - compatible + +examples: + - | + bus@c0000000 { + compatible = "arm,integrator-ap-lm"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0xc0000000 0xc0000000 0x40000000>; + dma-ranges; + + bus@c0000000 { + compatible = "simple-bus"; + ranges = <0x00000000 0xc0000000 0x10000000>; + /* The Logic Modules sees the Core Module 0 RAM @80000000 */ + dma-ranges = <0x00000000 0x80000000 0x10000000>; + #address-cells = <1>; + #size-cells = <1>; + + serial@100000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x00100000 0x1000>; + interrupts-extended = <&impd1_vic 1>; + }; + + impd1_vic: interrupt-controller@3000000 { + compatible = "arm,pl192-vic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x03000000 0x1000>; + valid-mask = <0x00000bff>; + interrupts-extended = <&pic 9>; + }; + }; + }; + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml new file mode 100644 index 000000000..37ba3337f --- /dev/null +++ b/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/baikal,bt1-apb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 APB-bus + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: | + Baikal-T1 CPU or DMAC MMIO requests are handled by the AMBA 3 AXI Interconnect + which routes them to the AXI-APB bridge. This interface is a single master + multiple slaves bus in turn serializing IO accesses and routing them to the + addressed APB slave devices. In case of any APB protocol collisions, slave + device not responding on timeout an IRQ is raised with an erroneous address + reported to the APB terminator (APB Errors Handler Block). + +allOf: + - $ref: /schemas/simple-bus.yaml# + +properties: + compatible: + contains: + const: baikal,bt1-apb + + reg: + items: + - description: APB EHB MMIO registers + - description: APB MMIO region with no any device mapped + + reg-names: + items: + - const: ehb + - const: nodev + + interrupts: + maxItems: 1 + + clocks: + items: + - description: APB reference clock + + clock-names: + items: + - const: pclk + + resets: + items: + - description: APB domain reset line + + reset-names: + items: + - const: prst + +unevaluatedProperties: false + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/interrupt-controller/mips-gic.h> + + bus@1f059000 { + compatible = "baikal,bt1-apb", "simple-bus"; + reg = <0x1f059000 0x1000>, + <0x1d000000 0x2040000>; + reg-names = "ehb", "nodev"; + #address-cells = <1>; + #size-cells = <1>; + + ranges; + + interrupts = <GIC_SHARED 16 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&ccu_sys 1>; + clock-names = "pclk"; + + resets = <&ccu_sys 1>; + reset-names = "prst"; + }; +... diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml new file mode 100644 index 000000000..0bee46945 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/baikal,bt1-axi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 AXI-bus + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: | + AXI3-bus is the main communication bus of Baikal-T1 SoC connecting all + high-speed peripheral IP-cores with RAM controller and with MIPS P5600 + cores. Traffic arbitration is done by means of DW AXI Interconnect (so + called AXI Main Interconnect) routing IO requests from one block to + another: from CPU to SoC peripherals and between some SoC peripherals + (mostly between peripheral devices and RAM, but also between DMA and + some peripherals). In case of any protocol error, device not responding + an IRQ is raised and a faulty situation is reported to the AXI EHB + (Errors Handler Block) embedded on top of the DW AXI Interconnect and + accessible by means of the Baikal-T1 System Controller. + +allOf: + - $ref: /schemas/simple-bus.yaml# + +properties: + compatible: + contains: + const: baikal,bt1-axi + + reg: + minItems: 1 + items: + - description: Synopsys DesignWare AXI Interconnect QoS registers + - description: AXI EHB MMIO system controller registers + + reg-names: + minItems: 1 + items: + - const: qos + - const: ehb + + '#interconnect-cells': + const: 1 + + syscon: + $ref: /schemas/types.yaml#definitions/phandle + description: Phandle to the Baikal-T1 System Controller DT node + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Main Interconnect uplink reference clock + + clock-names: + items: + - const: aclk + + resets: + items: + - description: Main Interconnect reset line + + reset-names: + items: + - const: arst + +unevaluatedProperties: false + +required: + - compatible + - reg + - reg-names + - syscon + - interrupts + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/interrupt-controller/mips-gic.h> + + bus@1f05a000 { + compatible = "baikal,bt1-axi", "simple-bus"; + reg = <0x1f05a000 0x1000>, + <0x1f04d110 0x8>; + reg-names = "qos", "ehb"; + #address-cells = <1>; + #size-cells = <1>; + #interconnect-cells = <1>; + + syscon = <&syscon>; + + ranges; + + interrupts = <GIC_SHARED 127 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&ccu_axi 0>; + clock-names = "aclk"; + + resets = <&ccu_axi 0>; + reset-names = "arst"; + }; +... diff --git a/Documentation/devicetree/bindings/bus/brcm,bus-axi.txt b/Documentation/devicetree/bindings/bus/brcm,bus-axi.txt new file mode 100644 index 000000000..edd44d802 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/brcm,bus-axi.txt @@ -0,0 +1,53 @@ +Driver for ARM AXI Bus with Broadcom Plugins (bcma) + +Required properties: + +- compatible : brcm,bus-axi + +- reg : iomem address range of chipcommon core + +The cores on the AXI bus are automatically detected by bcma with the +memory ranges they are using and they get registered afterwards. +Automatic detection of the IRQ number is not working on +BCM47xx/BCM53xx ARM SoCs. To assign IRQ numbers to the cores, provide +them manually through device tree. Use an interrupt-map to specify the +IRQ used by the devices on the bus. The first address is just an index, +because we do not have any special register. + +The top-level axi bus may contain children representing attached cores +(devices). This is needed since some hardware details can't be auto +detected (e.g. IRQ numbers). Also some of the cores may be responsible +for extra things, e.g. ChipCommon providing access to the GPIO chip. + +Example: + + axi@18000000 { + compatible = "brcm,bus-axi"; + reg = <0x18000000 0x1000>; + ranges = <0x00000000 0x18000000 0x00100000>; + #address-cells = <1>; + #size-cells = <1>; + #interrupt-cells = <1>; + interrupt-map-mask = <0x000fffff 0xffff>; + interrupt-map = + /* Ethernet Controller 0 */ + <0x00024000 0 &gic GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, + + /* Ethernet Controller 1 */ + <0x00025000 0 &gic GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; + + /* PCIe Controller 0 */ + <0x00012000 0 &gic GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>, + <0x00012000 1 &gic GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>, + <0x00012000 2 &gic GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>, + <0x00012000 3 &gic GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>, + <0x00012000 4 &gic GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>, + <0x00012000 5 &gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>; + + chipcommon { + reg = <0x00000000 0x1000>; + + gpio-controller; + #gpio-cells = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt new file mode 100644 index 000000000..10f6d0a81 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt @@ -0,0 +1,34 @@ +Broadcom GISB bus Arbiter controller + +Required properties: + +- compatible: + "brcm,bcm7278-gisb-arb" for V7 28nm chips + "brcm,gisb-arb" or "brcm,bcm7445-gisb-arb" for other 28nm chips + "brcm,bcm7435-gisb-arb" for newer 40nm chips + "brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips + "brcm,bcm7038-gisb-arb" for 130nm chips +- reg: specifies the base physical address and size of the registers +- interrupts: specifies the two interrupts (timeout and TEA) to be used from + the parent interrupt controller. A third optional interrupt may be specified + for breakpoints. + +Optional properties: + +- brcm,gisb-arb-master-mask: 32-bits wide bitmask used to specify which GISB + masters are valid at the system level +- brcm,gisb-arb-master-names: string list of the litteral name of the GISB + masters. Should match the number of bits set in brcm,gisb-master-mask and + the order in which they appear + +Example: + +gisb-arb@f0400000 { + compatible = "brcm,gisb-arb"; + reg = <0xf0400000 0x800>; + interrupts = <0>, <2>; + interrupt-parent = <&sun_l2_intc>; + + brcm,gisb-arb-master-mask = <0x7>; + brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0"; +}; diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt new file mode 100644 index 000000000..1b1d1c5c2 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt @@ -0,0 +1,112 @@ +Device tree bindings for i.MX Wireless External Interface Module (WEIM) + +The term "wireless" does not imply that the WEIM is literally an interface +without wires. It simply means that this module was originally designed for +wireless and mobile applications that use low-power technology. + +The actual devices are instantiated from the child nodes of a WEIM node. + +Required properties: + + - compatible: Should contain one of the following: + "fsl,imx1-weim" + "fsl,imx27-weim" + "fsl,imx51-weim" + "fsl,imx50-weim" + "fsl,imx6q-weim" + - reg: A resource specifier for the register space + (see the example below) + - clocks: the clock, see the example below. + - #address-cells: Must be set to 2 to allow memory address translation + - #size-cells: Must be set to 1 to allow CS address passing + - ranges: Must be set up to reflect the memory layout with four + integer values for each chip-select line in use: + + <cs-number> 0 <physical address of mapping> <size> + +Optional properties: + + - fsl,weim-cs-gpr: For "fsl,imx50-weim" and "fsl,imx6q-weim" type of + devices, it should be the phandle to the system General + Purpose Register controller that contains WEIM CS GPR + register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0] + should be set up as one of the following 4 possible + values depending on the CS space configuration. + + IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3 + --------------------------------------------- + 05 128M 0M 0M 0M + 033 64M 64M 0M 0M + 0113 64M 32M 32M 0M + 01111 32M 32M 32M 32M + + In case that the property is absent, the reset value or + what bootloader sets up in IOMUXC_GPR1[11:0] will be + used. + + - fsl,burst-clk-enable For "fsl,imx50-weim" and "fsl,imx6q-weim" type of + devices, the presence of this property indicates that + the weim bus should operate in Burst Clock Mode. + +Timing property for child nodes. It is mandatory, not optional. + + - fsl,weim-cs-timing: The timing array, contains timing values for the + child node. We get the CS indexes from the address + ranges in the child node's "reg" property. + The number of registers depends on the selected chip: + For i.MX1, i.MX21 ("fsl,imx1-weim") there are two + registers: CSxU, CSxL. + For i.MX25, i.MX27, i.MX31 and i.MX35 ("fsl,imx27-weim") + there are three registers: CSCRxU, CSCRxL, CSCRxA. + For i.MX50, i.MX53 ("fsl,imx50-weim"), + i.MX51 ("fsl,imx51-weim") and i.MX6Q ("fsl,imx6q-weim") + there are six registers: CSxGCR1, CSxGCR2, CSxRCR1, + CSxRCR2, CSxWCR1, CSxWCR2. + +Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM: + + weim: weim@21b8000 { + compatible = "fsl,imx6q-weim"; + reg = <0x021b8000 0x4000>; + clocks = <&clks 196>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0x08000000 0x08000000>; + fsl,weim-cs-gpr = <&gpr>; + + nor@0,0 { + compatible = "cfi-flash"; + reg = <0 0 0x02000000>; + #address-cells = <1>; + #size-cells = <1>; + bank-width = <2>; + fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000 + 0x0000c000 0x1404a38e 0x00000000>; + }; + }; + +Example for an imx6q-based board, a multi-chipselect device connected to WEIM: + +In this case, both chip select 0 and 1 will be configured with the same timing +array values. + + weim: weim@21b8000 { + compatible = "fsl,imx6q-weim"; + reg = <0x021b8000 0x4000>; + clocks = <&clks 196>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0x08000000 0x02000000 + 1 0 0x0a000000 0x02000000 + 2 0 0x0c000000 0x02000000 + 3 0 0x0e000000 0x02000000>; + fsl,weim-cs-gpr = <&gpr>; + + acme@0 { + compatible = "acme,whatever"; + reg = <0 0 0x100>, <0 0x400000 0x800>, + <1 0x400000 0x800>; + fsl,weim-cs-timing = <0x024400b1 0x00001010 0x20081100 + 0x00000000 0xa0000240 0x00000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/moxtet.txt b/Documentation/devicetree/bindings/bus/moxtet.txt new file mode 100644 index 000000000..fb50fc865 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/moxtet.txt @@ -0,0 +1,46 @@ +Turris Mox module status and configuration bus (over SPI) + +Required properties: + - compatible : Should be "cznic,moxtet" + - #address-cells : Has to be 1 + - #size-cells : Has to be 0 + - spi-cpol : Required inverted clock polarity + - spi-cpha : Required shifted clock phase + - interrupts : Must contain reference to the shared interrupt line + - interrupt-controller : Required + - #interrupt-cells : Has to be 1 + +For other required and optional properties of SPI slave nodes please refer to +../spi/spi-bus.txt. + +Required properties of subnodes: + - reg : Should be position on the Moxtet bus (how many Moxtet + modules are between this module and CPU module, so + either 0 or a positive integer) + +The driver finds the devices connected to the bus by itself, but it may be +needed to reference some of them from other parts of the device tree. In that +case the devices can be defined as subnodes of the moxtet node. + +Example: + + moxtet@1 { + compatible = "cznic,moxtet"; + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + spi-max-frequency = <10000000>; + spi-cpol; + spi-cpha; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&gpiosb>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + + moxtet_sfp: gpio@0 { + compatible = "cznic,moxtet-gpio"; + gpio-controller; + #gpio-cells = <2>; + reg = <0>; + } + }; diff --git a/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml b/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml new file mode 100644 index 000000000..6a7b26b04 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/mti,mips-cdmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MIPS Common Device Memory Map + +description: | + Defines a location of the MIPS Common Device Memory Map registers. + +maintainers: + - James Hogan <jhogan@kernel.org> + +properties: + compatible: + const: mti,mips-cdmm + + reg: + description: | + Base address and size of an unoccupied memory region, which will be + used to map the MIPS CDMM registers block. + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + cdmm@1bde8000 { + compatible = "mti,mips-cdmm"; + reg = <0x1bde8000 0x8000>; + }; +... diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt new file mode 100644 index 000000000..f2ab7fd01 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt @@ -0,0 +1,276 @@ + +* Marvell MBus + +Required properties: + +- compatible: Should be set to one of the following: + marvell,armada370-mbus + marvell,armadaxp-mbus + marvell,armada375-mbus + marvell,armada380-mbus + marvell,kirkwood-mbus + marvell,dove-mbus + marvell,orion5x-88f5281-mbus + marvell,orion5x-88f5182-mbus + marvell,orion5x-88f5181-mbus + marvell,orion5x-88f6183-mbus + marvell,mv78xx0-mbus + +- address-cells: Must be '2'. The first cell for the MBus ID encoding, + the second cell for the address offset within the window. + +- size-cells: Must be '1'. + +- ranges: Must be set up to provide a proper translation for each child. + See the examples below. + +- controller: Contains a single phandle referring to the MBus controller + node. This allows to specify the node that contains the + registers that control the MBus, which is typically contained + within the internal register window (see below). + +Optional properties: + +- pcie-mem-aperture: This optional property contains the aperture for + the memory region of the PCIe driver. + If it's defined, it must encode the base address and + size for the address decoding windows allocated for + the PCIe memory region. + +- pcie-io-aperture: Just as explained for the above property, this + optional property contains the aperture for the + I/O region of the PCIe driver. + +* Marvell MBus controller + +Required properties: + +- compatible: Should be set to "marvell,mbus-controller". + +- reg: Device's register space. + Two or three entries are expected (see the examples below): + the first one controls the devices decoding window, + the second one controls the SDRAM decoding window and + the third controls the MBus bridge (only with the + marvell,armada370-mbus and marvell,armadaxp-mbus + compatible strings) + +Example: + + soc { + compatible = "marvell,armada370-mbus", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + controller = <&mbusc>; + pcie-mem-aperture = <0xe0000000 0x8000000>; + pcie-io-aperture = <0xe8000000 0x100000>; + + internal-regs { + compatible = "simple-bus"; + + mbusc: mbus-controller@20000 { + compatible = "marvell,mbus-controller"; + reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>; + }; + + /* more children ...*/ + }; + }; + +** MBus address decoding window specification + +The MBus children address space is comprised of two cells: the first one for +the window ID and the second one for the offset within the window. +In order to allow to describe valid and non-valid window entries, the +following encoding is used: + + 0xSIAA0000 0x00oooooo + +Where: + + S = 0x0 for a MBus valid window + S = 0xf for a non-valid window (see below) + +If S = 0x0, then: + + I = 4-bit window target ID + AA = windpw attribute + +If S = 0xf, then: + + I = don't care + AA = 1 for internal register + +Following the above encoding, for each ranges entry for a MBus valid window +(S = 0x0), an address decoding window is allocated. On the other side, +entries for translation that do not correspond to valid windows (S = 0xf) +are skipped. + + soc { + compatible = "marvell,armada370-mbus", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + controller = <&mbusc>; + + ranges = <0xf0010000 0 0 0xd0000000 0x100000 + 0x01e00000 0 0 0xfff00000 0x100000>; + + bootrom { + compatible = "marvell,bootrom"; + reg = <0x01e00000 0 0x100000>; + }; + + /* other children */ + ... + + internal-regs { + compatible = "simple-bus"; + ranges = <0 0xf0010000 0 0x100000>; + + mbusc: mbus-controller@20000 { + compatible = "marvell,mbus-controller"; + reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>; + }; + + /* more children ...*/ + }; + }; + +In the shown example, the translation entry in the 'ranges' property is what +makes the MBus driver create a static decoding window for the corresponding +given child device. Note that the binding does not require child nodes to be +present. Of course, child nodes are needed to probe the devices. + +Since each window is identified by its target ID and attribute ID there's +a special macro that can be use to simplify the translation entries: + +#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16)) + +Using this macro, the above example would be: + + soc { + compatible = "marvell,armada370-mbus", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + controller = <&mbusc>; + + ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>; + + bootrom { + compatible = "marvell,bootrom"; + reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>; + }; + + /* other children */ + ... + + internal-regs { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>; + + mbusc: mbus-controller@20000 { + compatible = "marvell,mbus-controller"; + reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>; + }; + + /* other children */ + ... + }; + }; + + +** About the window base address + +Remember the MBus controller allows a great deal of flexibility for choosing +the decoding window base address. When planning the device tree layout it's +possible to choose any address as the base address, provided of course there's +a region large enough available, and with the required alignment. + +Yet in other words: there's nothing preventing us from setting a base address +of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is +unused. + +** Window allocation policy + +The mbus-node ranges property defines a set of mbus windows that are expected +to be set by the operating system and that are guaranteed to be free of overlaps +with one another or with the system memory ranges. + +Each entry in the property refers to exactly one window. If the operating system +chooses to use a different set of mbus windows, it must ensure that any address +translations performed from downstream devices are adapted accordingly. + +The operating system may insert additional mbus windows that do not conflict +with the ones listed in the ranges, e.g. for mapping PCIe devices. +As a special case, the internal register window must be set up by the boot +loader at the address listed in the ranges property, since access to that region +is needed to set up the other windows. + +** Example + +See the example below, where a more complete device tree is shown: + + soc { + compatible = "marvell,armadaxp-mbus", "simple-bus"; + controller = <&mbusc>; + + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 /* internal-regs */ + MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 + MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>; + + bootrom { + compatible = "marvell,bootrom"; + reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>; + }; + + devbus-bootcs { + ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>; + + /* NOR */ + nor { + compatible = "cfi-flash"; + reg = <0 0x8000000>; + bank-width = <2>; + }; + }; + + pcie-controller { + compatible = "marvell,armada-xp-pcie"; + device_type = "pci"; + + #address-cells = <3>; + #size-cells = <2>; + + ranges = + <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */ + 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */ + 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */ + 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */ + 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */ + 0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */ + 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>; + + + pcie@1,0 { + /* Port 0, Lane 0 */ + }; + }; + + internal-regs { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>; + + mbusc: mbus-controller@20000 { + reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>; + }; + + interrupt-controller@20000 { + reg = <0x20a00 0x2d0>, <0x21070 0x58>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt new file mode 100644 index 000000000..c1e706217 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt @@ -0,0 +1,128 @@ +Device tree bindings for NVIDIA Tegra Generic Memory Interface bus + +The Generic Memory Interface bus enables memory transfers between internal and +external memory. Can be used to attach various high speed devices such as +synchronous/asynchronous NOR, FPGA, UARTS and more. + +The actual devices are instantiated from the child nodes of a GMI node. + +Required properties: + - compatible : Should contain one of the following: + For Tegra20 must contain "nvidia,tegra20-gmi". + For Tegra30 must contain "nvidia,tegra30-gmi". + - reg: Should contain GMI controller registers location and length. + - clocks: Must contain an entry for each entry in clock-names. + - clock-names: Must include the following entries: "gmi" + - resets : Must contain an entry for each entry in reset-names. + - reset-names : Must include the following entries: "gmi" + - #address-cells: The number of cells used to represent physical base + addresses in the GMI address space. Should be 2. + - #size-cells: The number of cells used to represent the size of an address + range in the GMI address space. Should be 1. + - ranges: Must be set up to reflect the memory layout with three integer values + for each chip-select line in use (only one entry is supported, see below + comments): + <cs-number> <offset> <physical address of mapping> <size> + +Note that the GMI controller does not have any internal chip-select address +decoding, because of that chip-selects either need to be managed via software +or by employing external chip-select decoding logic. + +If external chip-select logic is used to support multiple devices it is assumed +that the devices use the same timing and so are probably the same type. It also +assumes that they can fit in the 256MB address range. In this case only one +child device is supported which represents the active chip-select line, see +examples for more insight. + +The chip-select number is decoded from the child nodes second address cell of +'ranges' property, if 'ranges' property is not present or empty chip-select will +then be decoded from the first cell of the 'reg' property. + +Optional child cs node properties: + + - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit. + - nvidia,snor-mux-mode: Enable address/data MUX mode. + - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data. + If omitted it will be asserted with data. + - nvidia,snor-rdy-active-high: RDY signal is active high + - nvidia,snor-adv-active-high: ADV signal is active high + - nvidia,snor-oe-active-high: WE/OE signal is active high + - nvidia,snor-cs-active-high: CS signal is active high + + Note that there is some special handling for the timing values. + From Tegra TRM: + Programming 0 means 1 clock cycle: actual cycle = programmed cycle + 1 + + - nvidia,snor-muxed-width: Number of cycles MUX address/data asserted on the + bus. Valid values are 0-15, default is 1 + - nvidia,snor-hold-width: Number of cycles CE stays asserted after the + de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N + (in case of MASTER Request). Valid values are 0-15, default is 1 + - nvidia,snor-adv-width: Number of cycles during which ADV stays asserted. + Valid values are 0-15, default is 1. + - nvidia,snor-ce-width: Number of cycles before CE is asserted. + Valid values are 0-15, default is 4 + - nvidia,snor-we-width: Number of cycles during which WE stays asserted. + Valid values are 0-15, default is 1 + - nvidia,snor-oe-width: Number of cycles during which OE stays asserted. + Valid values are 0-255, default is 1 + - nvidia,snor-wait-width: Number of cycles before READY is asserted. + Valid values are 0-255, default is 3 + +Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the +controllers with a simple-bus node since they are all connected to the same +chip-select (CS4), in this example external address decoding is provided: + +gmi@70009000 { + compatible = "nvidia,tegra20-gmi"; + reg = <0x70009000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + clocks = <&tegra_car TEGRA20_CLK_NOR>; + clock-names = "gmi"; + resets = <&tegra_car 42>; + reset-names = "gmi"; + ranges = <4 0 0xd0000000 0xfffffff>; + + bus@4,0 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 4 0 0x40100>; + + nvidia,snor-mux-mode; + nvidia,snor-adv-active-high; + + can@0 { + reg = <0 0x100>; + ... + }; + + can@40000 { + reg = <0x40000 0x100>; + ... + }; + }; +}; + +Example with one SJA1000 CAN controller connected to the GMI bus +on CS4: + +gmi@70009000 { + compatible = "nvidia,tegra20-gmi"; + reg = <0x70009000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + clocks = <&tegra_car TEGRA20_CLK_NOR>; + clock-names = "gmi"; + resets = <&tegra_car 42>; + reset-names = "gmi"; + ranges = <4 0 0xd0000000 0xfffffff>; + + can@4,0 { + reg = <4 0 0x100>; + nvidia,snor-mux-mode; + nvidia,snor-adv-active-high; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt new file mode 100644 index 000000000..3108d0380 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt @@ -0,0 +1,44 @@ +NVIDIA Tegra ACONNECT Bus + +The Tegra ACONNECT bus is an AXI switch which is used to connnect various +components inside the Audio Processing Engine (APE). All CPU accesses to +the APE subsystem go through the ACONNECT via an APB to AXI wrapper. + +Required properties: +- compatible: Must be "nvidia,tegra210-aconnect". +- clocks: Must contain the entries for the APE clock (TEGRA210_CLK_APE), + and APE interface clock (TEGRA210_CLK_APB2APE). +- clock-names: Must contain the names "ape" and "apb2ape" for the corresponding + 'clocks' entries. +- power-domains: Must contain a phandle that points to the audio powergate + (namely 'aud') for Tegra210. +- #address-cells: The number of cells used to represent physical base addresses + in the aconnect address space. Should be 1. +- #size-cells: The number of cells used to represent the size of an address + range in the aconnect address space. Should be 1. +- ranges: Mapping of the aconnect address space to the CPU address space. + +All devices accessed via the ACONNNECT are described by child-nodes. + +Example: + + aconnect@702c0000 { + compatible = "nvidia,tegra210-aconnect"; + clocks = <&tegra_car TEGRA210_CLK_APE>, + <&tegra_car TEGRA210_CLK_APB2APE>; + clock-names = "ape", "apb2ape"; + power-domains = <&pd_audio>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x702c0000 0x0 0x702c0000 0x00040000>; + + + child1 { + ... + }; + + child2 { + ... + }; + }; diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt new file mode 100644 index 000000000..18729f6fe --- /dev/null +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -0,0 +1,29 @@ +* OMAP OCP2SCP - ocp interface to scp interface + +properties: +- compatible : Should be "ti,am437x-ocp2scp" for AM437x processor + Should be "ti,omap-ocp2scp" for all others +- reg : Address and length of the register set for the device +- #address-cells, #size-cells : Must be present if the device has sub-nodes +- ranges : the child address space are mapped 1:1 onto the parent address space +- ti,hwmods : must be "ocp2scp_usb_phy" + +Sub-nodes: +All the devices connected to ocp2scp are described using sub-node to ocp2scp + +ocp2scp@4a0ad000 { + compatible = "ti,omap-ocp2scp"; + reg = <0x4a0ad000 0x1f>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + ti,hwmods = "ocp2scp_usb_phy"; + + subnode1 { + ... + }; + + subnode2 { + ... + }; +}; diff --git a/Documentation/devicetree/bindings/bus/qcom,ebi2.txt b/Documentation/devicetree/bindings/bus/qcom,ebi2.txt new file mode 100644 index 000000000..5058aa2c6 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/qcom,ebi2.txt @@ -0,0 +1,138 @@ +Qualcomm External Bus Interface 2 (EBI2) + +The EBI2 contains two peripheral blocks: XMEM and LCDC. The XMEM handles any +external memory (such as NAND or other memory-mapped peripherals) whereas +LCDC handles LCD displays. + +As it says it connects devices to an external bus interface, meaning address +lines (up to 9 address lines so can only address 1KiB external memory space), +data lines (16 bits), OE (output enable), ADV (address valid, used on some +NOR flash memories), WE (write enable). This on top of 6 different chip selects +(CS0 thru CS5) so that in theory 6 different devices can be connected. + +Apparently this bus is clocked at 64MHz. It has dedicated pins on the package +and the bus can only come out on these pins, however if some of the pins are +unused they can be left unconnected or remuxed to be used as GPIO or in some +cases other orthogonal functions as well. + +Also CS1 and CS2 has -A and -B signals. Why they have that is unclear to me. + +The chip selects have the following memory range assignments. This region of +memory is referred to as "Chip Peripheral SS FPB0" and is 168MB big. + +Chip Select Physical address base +CS0 GPIO134 0x1a800000-0x1b000000 (8MB) +CS1 GPIO39 (A) / GPIO123 (B) 0x1b000000-0x1b800000 (8MB) +CS2 GPIO40 (A) / GPIO124 (B) 0x1b800000-0x1c000000 (8MB) +CS3 GPIO133 0x1d000000-0x25000000 (128 MB) +CS4 GPIO132 0x1c800000-0x1d000000 (8MB) +CS5 GPIO131 0x1c000000-0x1c800000 (8MB) + +The APQ8060 Qualcomm Application Processor User Guide, 80-N7150-14 Rev. A, +August 6, 2012 contains some incomplete documentation of the EBI2. + +FIXME: the manual mentions "write precharge cycles" and "precharge cycles". +We have not been able to figure out which bit fields these correspond to +in the hardware, or what valid values exist. The current hypothesis is that +this is something just used on the FAST chip selects and that the SLOW +chip selects are understood fully. There is also a "byte device enable" +flag somewhere for 8bit memories. + +FIXME: The chipselects have SLOW and FAST configuration registers. It's a bit +unclear what this means, if they are mutually exclusive or can be used +together, or if some chip selects are hardwired to be FAST and others are SLOW +by design. + +The XMEM registers are totally undocumented but could be partially decoded +because the Cypress AN49576 Antioch Westbridge apparently has suspiciously +similar register layout, see: http://www.cypress.com/file/105771/download + +Required properties: +- compatible: should be one of: + "qcom,msm8660-ebi2" + "qcom,apq8060-ebi2" +- #address-cells: should be <2>: the first cell is the chipselect, + the second cell is the offset inside the memory range +- #size-cells: should be <1> +- ranges: should be set to: + ranges = <0 0x0 0x1a800000 0x00800000>, + <1 0x0 0x1b000000 0x00800000>, + <2 0x0 0x1b800000 0x00800000>, + <3 0x0 0x1d000000 0x08000000>, + <4 0x0 0x1c800000 0x00800000>, + <5 0x0 0x1c000000 0x00800000>; +- reg: two ranges of registers: EBI2 config and XMEM config areas +- reg-names: should be "ebi2", "xmem" +- clocks: two clocks, EBI_2X and EBI +- clock-names: should be "ebi2x", "ebi2" + +Optional subnodes: +- Nodes inside the EBI2 will be considered device nodes. + +The following optional properties are properties that can be tagged onto +any device subnode. We are assuming that there can be only ONE device per +chipselect subnode, else the properties will become ambiguous. + +Optional properties arrays for SLOW chip selects: +- qcom,xmem-recovery-cycles: recovery cycles is the time the memory continues to + drive the data bus after OE is de-asserted, in order to avoid contention on + the data bus. They are inserted when reading one CS and switching to another + CS or read followed by write on the same CS. Valid values 0 thru 15. Minimum + value is actually 1, so a value of 0 will still yield 1 recovery cycle. +- qcom,xmem-write-hold-cycles: write hold cycles, these are extra cycles + inserted after every write minimum 1. The data out is driven from the time + WE is asserted until CS is asserted. With a hold of 1 (value = 0), the CS + stays active for 1 extra cycle etc. Valid values 0 thru 15. +- qcom,xmem-write-delta-cycles: initial latency for write cycles inserted for + the first write to a page or burst memory. Valid values 0 thru 255. +- qcom,xmem-read-delta-cycles: initial latency for read cycles inserted for the + first read to a page or burst memory. Valid values 0 thru 255. +- qcom,xmem-write-wait-cycles: number of wait cycles for every write access, 0=1 + cycle. Valid values 0 thru 15. +- qcom,xmem-read-wait-cycles: number of wait cycles for every read access, 0=1 + cycle. Valid values 0 thru 15. + +Optional properties arrays for FAST chip selects: +- qcom,xmem-address-hold-enable: this is a boolean property stating that we + shall hold the address for an extra cycle to meet hold time requirements + with ADV assertion. +- qcom,xmem-adv-to-oe-recovery-cycles: the number of cycles elapsed before an OE + assertion, with respect to the cycle where ADV (address valid) is asserted. + 2 means 2 cycles between ADV and OE. Valid values 0, 1, 2 or 3. +- qcom,xmem-read-hold-cycles: the length in cycles of the first segment of a + read transfer. For a single read transfer this will be the time from CS + assertion to OE assertion. Valid values 0 thru 15. + + +Example: + +ebi2@1a100000 { + compatible = "qcom,apq8060-ebi2"; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0x0 0x1a800000 0x00800000>, + <1 0x0 0x1b000000 0x00800000>, + <2 0x0 0x1b800000 0x00800000>, + <3 0x0 0x1d000000 0x08000000>, + <4 0x0 0x1c800000 0x00800000>, + <5 0x0 0x1c000000 0x00800000>; + reg = <0x1a100000 0x1000>, <0x1a110000 0x1000>; + reg-names = "ebi2", "xmem"; + clocks = <&gcc EBI2_2X_CLK>, <&gcc EBI2_CLK>; + clock-names = "ebi2x", "ebi2"; + /* Make sure to set up the pin control for the EBI2 */ + pinctrl-names = "default"; + pinctrl-0 = <&foo_ebi2_pins>; + + foo-ebi2@2,0 { + compatible = "foo"; + reg = <2 0x0 0x100>; + (...) + qcom,xmem-recovery-cycles = <0>; + qcom,xmem-write-hold-cycles = <3>; + qcom,xmem-write-delta-cycles = <31>; + qcom,xmem-read-delta-cycles = <28>; + qcom,xmem-write-wait-cycles = <9>; + qcom,xmem-read-wait-cycles = <9>; + }; +}; diff --git a/Documentation/devicetree/bindings/bus/renesas,bsc.yaml b/Documentation/devicetree/bindings/bus/renesas,bsc.yaml new file mode 100644 index 000000000..f53a37785 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/renesas,bsc.yaml @@ -0,0 +1,62 @@ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/renesas,bsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Bus State Controller (BSC) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: | + The Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus + Bridge", or "External Bus Interface") can be found in several Renesas ARM + SoCs. It provides an external bus for connecting multiple external + devices to the SoC, driving several chip select lines, for e.g. NOR + FLASH, Ethernet and USB. + + While the BSC is a fairly simple memory-mapped bus, it may be part of a + PM domain, and may have a gateable functional clock. Before a device + connected to the BSC can be accessed, the PM domain containing the BSC + must be powered on, and the functional clock driving the BSC must be + enabled. + + The bindings for the BSC extend the bindings for "simple-pm-bus". + +allOf: + - $ref: simple-pm-bus.yaml# + +properties: + compatible: + items: + - enum: + - renesas,bsc-r8a73a4 # R-Mobile APE6 (r8a73a4) + - renesas,bsc-sh73a0 # SH-Mobile AG5 (sh73a0) + - const: renesas,bsc + - {} # simple-pm-bus, but not listed here to avoid false select + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + bsc: bus@fec10000 { + compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x20000000>; + reg = <0xfec10000 0x400>; + interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&zb_clk>; + power-domains = <&pd_a4s>; + }; diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.yaml b/Documentation/devicetree/bindings/bus/simple-pm-bus.yaml new file mode 100644 index 000000000..182134d7a --- /dev/null +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/simple-pm-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple Power-Managed Bus + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: | + A Simple Power-Managed Bus is a transparent bus that doesn't need a real + driver, as it's typically initialized by the boot loader. + + However, its bus controller is part of a PM domain, or under the control + of a functional clock. Hence, the bus controller's PM domain and/or + clock must be enabled for child devices connected to the bus (either + on-SoC or externally) to function. + + While "simple-pm-bus" follows the "simple-bus" set of properties, as + specified in the Devicetree Specification, it is not an extension of + "simple-bus". + +properties: + $nodename: + pattern: "^bus(@[0-9a-f]+)?$" + + compatible: + contains: + const: simple-pm-bus + description: + Shall contain "simple-pm-bus" in addition to a optional bus-specific + compatible strings defined in individual pm-bus bindings. + + '#address-cells': + enum: [ 1, 2 ] + + '#size-cells': + enum: [ 1, 2 ] + + ranges: true + + clocks: true + # Functional clocks + # Required if power-domains is absent, optional otherwise + + power-domains: + # Required if clocks is absent, optional otherwise + minItems: 1 + +required: + - compatible + - '#address-cells' + - '#size-cells' + - ranges + +anyOf: + - required: + - clocks + - required: + - power-domains + +additionalProperties: true + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-msm8996.h> + #include <dt-bindings/interrupt-controller/irq.h> + + bus { + power-domains = <&gcc AGGRE0_NOC_GDSC>; + compatible = "simple-pm-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + }; diff --git a/Documentation/devicetree/bindings/bus/socionext,uniphier-system-bus.yaml b/Documentation/devicetree/bindings/bus/socionext,uniphier-system-bus.yaml new file mode 100644 index 000000000..49df13fc2 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/socionext,uniphier-system-bus.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/socionext,uniphier-system-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: UniPhier System Bus + +description: | + The UniPhier System Bus is an external bus that connects on-board devices to + the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and + some control signals. It supports up to 8 banks (chip selects). + + Before any access to the bus, the bus controller must be configured; the bus + controller registers provide the control for the translation from the offset + within each bank to the CPU-viewed address. The needed setup includes the + base address, the size of each bank. Optionally, some timing parameters can + be optimized for faster bus access. + +maintainers: + - Masahiro Yamada <yamada.masahiro@socionext.com> + +properties: + compatible: + const: socionext,uniphier-system-bus + + reg: + maxItems: 1 + + "#address-cells": + description: | + The first cell is the bank number (chip select). + The second cell is the address offset within the bank. + const: 2 + + "#size-cells": + const: 1 + + ranges: + description: | + Provide address translation from the System Bus to the parent bus. + + Note: + The address region(s) that can be assigned for the System Bus is + implementation defined. Some SoCs can use 0x00000000-0x0fffffff and + 0x40000000-0x4fffffff, while other SoCs only 0x40000000-0x4fffffff. + There might be additional limitations depending on SoCs and the boot mode. + The address translation is arbitrary as long as the banks are assigned in + the supported address space with the required alignment and they do not + overlap one another. + + For example, it is possible to map: + bank 0 to 0x42000000-0x43ffffff, bank 5 to 0x46000000-0x46ffffff + It is also possible to map: + bank 0 to 0x48000000-0x49ffffff, bank 5 to 0x44000000-0x44ffffff + There is no reason to stick to a particular translation mapping, but the + "ranges" property should provide a "reasonable" default that is known to + work. The software should initialize the bus controller according to it. + +patternProperties: + "^.*@[1-5],[1-9a-f][0-9a-f]+$": + description: Devices attached to chip selects + type: object + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + +additionalProperties: false + +examples: + - | + // In this example, + // - the Ethernet device is connected at the offset 0x01f00000 of CS1 and + // mapped to 0x43f00000 of the parent bus. + // - the UART device is connected at the offset 0x00200000 of CS5 and + // mapped to 0x46200000 of the parent bus. + + system-bus@58c00000 { + compatible = "socionext,uniphier-system-bus"; + reg = <0x58c00000 0x400>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <1 0x00000000 0x42000000 0x02000000>, + <5 0x00000000 0x46000000 0x01000000>; + + ethernet@1,1f00000 { + compatible = "smsc,lan9115"; + reg = <1 0x01f00000 0x1000>; + interrupts = <0 48 4>; + phy-mode = "mii"; + }; + + serial@5,200000 { + compatible = "ns16550a"; + reg = <5 0x00200000 0x20>; + interrupts = <0 49 4>; + clock-frequency = <12288000>; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt new file mode 100644 index 000000000..72daefc6b --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt @@ -0,0 +1,20 @@ +* Device tree bindings for Texas Instruments da8xx master peripheral + priority driver + +DA8XX SoCs feature a set of registers allowing to change the priority of all +peripherals classified as masters. + +Documentation: +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf + +Required properties: + +- compatible: "ti,da850-mstpri" - for da850 based boards +- reg: offset and length of the mstpri registers + +Example for da850-lcdk is shown below. + +mstpri { + compatible = "ti,da850-mstpri"; + reg = <0x14110 0x0c>; +}; diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt new file mode 100644 index 000000000..c984143d0 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt @@ -0,0 +1,139 @@ +Texas Instruments sysc interconnect target module wrapper binding + +Texas Instruments SoCs can have a generic interconnect target module +hardware for devices connected to various interconnects such as L3 +interconnect (Arteris NoC) and L4 interconnect (Sonics s3220). The sysc +is mostly used for interaction between module and PRCM. It participates +in the OCP Disconnect Protocol but other than that is mostly independent +of the interconnect. + +Each interconnect target module can have one or more devices connected to +it. There is a set of control registers for managing interconnect target +module clocks, idle modes and interconnect level resets for the module. + +These control registers are sprinkled into the unused register address +space of the first child device IP block managed by the interconnect +target module and typically are named REVISION, SYSCONFIG and SYSSTATUS. + +Required standard properties: + +- compatible shall be one of the following generic types: + + "ti,sysc" + "ti,sysc-omap2" + "ti,sysc-omap4" + "ti,sysc-omap4-simple" + + or one of the following derivative types for hardware + needing special workarounds: + + "ti,sysc-omap2-timer" + "ti,sysc-omap4-timer" + "ti,sysc-omap3430-sr" + "ti,sysc-omap3630-sr" + "ti,sysc-omap4-sr" + "ti,sysc-omap3-sham" + "ti,sysc-omap-aes" + "ti,sysc-mcasp" + "ti,sysc-dra7-mcasp" + "ti,sysc-usb-host-fs" + "ti,sysc-dra7-mcan" + "ti,sysc-pruss" + +- reg shall have register areas implemented for the interconnect + target module in question such as revision, sysc and syss + +- reg-names shall contain the register names implemented for the + interconnect target module in question such as + "rev, "sysc", and "syss" + +- ranges shall contain the interconnect target module IO range + available for one or more child device IP blocks managed + by the interconnect target module, the ranges may include + multiple ranges such as device L4 range for control and + parent L3 range for DMA access + +Optional properties: + +- ti,sysc-mask shall contain mask of supported register bits for the + SYSCONFIG register as documented in the Technical Reference + Manual (TRM) for the interconnect target module + +- ti,sysc-midle list of master idle modes supported by the interconnect + target module as documented in the TRM for SYSCONFIG + register MIDLEMODE bits + +- ti,sysc-sidle list of slave idle modes supported by the interconnect + target module as documented in the TRM for SYSCONFIG + register SIDLEMODE bits + +- ti,sysc-delay-us delay needed after OCP softreset before accssing + SYSCONFIG register again + +- ti,syss-mask optional mask of reset done status bits as described in the + TRM for SYSSTATUS registers, typically 1 with some devices + having separate reset done bits for children like OHCI and + EHCI + +- clocks clock specifier for each name in the clock-names as + specified in the binding documentation for ti-clkctrl, + typically available for all interconnect targets on TI SoCs + based on omap4 except if it's read-only register in hwauto + mode as for example omap4 L4_CFG_CLKCTRL + +- clock-names should contain at least "fck", and optionally also "ick" + depending on the SoC and the interconnect target module, + some interconnect target modules also need additional + optional clocks that can be specified as listed in TRM + for the related CLKCTRL register bits 8 to 15 such as + "dbclk" or "clk32k" depending on their role + +- ti,hwmods optional TI interconnect module name to use legacy + hwmod platform data + +- ti,no-reset-on-init interconnect target module should not be reset at init + +- ti,no-idle-on-init interconnect target module should not be idled at init + +- ti,no-idle interconnect target module should not be idled + +Example: Single instance of MUSB controller on omap4 using interconnect ranges +using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000): + + target-module@2b000 { /* 0x4a0ab000, ap 84 12.0 */ + compatible = "ti,sysc-omap2"; + ti,hwmods = "usb_otg_hs"; + reg = <0x2b400 0x4>, + <0x2b404 0x4>, + <0x2b408 0x4>; + reg-names = "rev", "sysc", "syss"; + clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>; + clock-names = "fck"; + ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP | + SYSC_OMAP2_SOFTRESET | + SYSC_OMAP2_AUTOIDLE)>; + ti,sysc-midle = <SYSC_IDLE_FORCE>, + <SYSC_IDLE_NO>, + <SYSC_IDLE_SMART>; + ti,sysc-sidle = <SYSC_IDLE_FORCE>, + <SYSC_IDLE_NO>, + <SYSC_IDLE_SMART>, + <SYSC_IDLE_SMART_WKUP>; + ti,syss-mask = <1>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x2b000 0x1000>; + + usb_otg_hs: otg@0 { + compatible = "ti,omap4-musb"; + reg = <0x0 0x7ff>; + interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>; + usb-phy = <&usb2_phy>; + ... + }; + }; + +Note that other SoCs, such as am335x can have multiple child devices. On am335x +there are two MUSB instances, two USB PHY instances, and a single CPPI41 DMA +instance as children of a single interconnect target module. diff --git a/Documentation/devicetree/bindings/bus/ts-nbus.txt b/Documentation/devicetree/bindings/bus/ts-nbus.txt new file mode 100644 index 000000000..2a10d065b --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ts-nbus.txt @@ -0,0 +1,50 @@ +Technologic Systems NBUS + +The NBUS is a bus used to interface with peripherals in the Technologic +Systems FPGA on the TS-4600 SoM. + +Required properties : + - compatible : "technologic,ts-nbus" + - #address-cells : must be 1 + - #size-cells : must be 0 + - pwms : The PWM bound to the FPGA + - ts,data-gpios : The 8 GPIO pins connected to the data lines on the FPGA + - ts,csn-gpios : The GPIO pin connected to the csn line on the FPGA + - ts,txrx-gpios : The GPIO pin connected to the txrx line on the FPGA + - ts,strobe-gpios : The GPIO pin connected to the stobe line on the FPGA + - ts,ale-gpios : The GPIO pin connected to the ale line on the FPGA + - ts,rdy-gpios : The GPIO pin connected to the rdy line on the FPGA + +Child nodes: + +The NBUS node can contain zero or more child nodes representing peripherals +on the bus. + +Example: + + nbus { + compatible = "technologic,ts-nbus"; + pinctrl-0 = <&nbus_pins>; + #address-cells = <1>; + #size-cells = <0>; + pwms = <&pwm 2 83>; + ts,data-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH + &gpio0 1 GPIO_ACTIVE_HIGH + &gpio0 2 GPIO_ACTIVE_HIGH + &gpio0 3 GPIO_ACTIVE_HIGH + &gpio0 4 GPIO_ACTIVE_HIGH + &gpio0 5 GPIO_ACTIVE_HIGH + &gpio0 6 GPIO_ACTIVE_HIGH + &gpio0 7 GPIO_ACTIVE_HIGH>; + ts,csn-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; + ts,txrx-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>; + ts,strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>; + ts,ale-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; + ts,rdy-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>; + + watchdog@2a { + compatible = "..."; + + /* ... */ + }; + }; |