summaryrefslogtreecommitdiffstats
path: root/dts/Bindings/bus
diff options
context:
space:
mode:
authorSascha Hauer <s.hauer@pengutronix.de>2014-04-25 11:22:32 +0200
committerSascha Hauer <s.hauer@pengutronix.de>2014-04-28 09:08:46 +0200
commit00ce25c6dcdae5582ae4be37147ab33678adc995 (patch)
tree41c93102ae304a61738c31353e3cb5336ef0b297 /dts/Bindings/bus
parent0af79fbb6779921d3f1962773adb7fb57d3c89d4 (diff)
downloadbarebox-00ce25c6dcdae5582ae4be37147ab33678adc995.tar.gz
barebox-00ce25c6dcdae5582ae4be37147ab33678adc995.tar.xz
Add devicetree source files as of Linux-3.15-rc2
This adds the Linux dts files to barebox. The dts files are generated from Ian Campbells device-tree-rebasing.git: git://xenbits.xen.org/people/ianc/device-tree-rebasing.git The dts are found in dts/ in the barebox repository and will be updated from upstream regularly, probably for each upstream -rc. To keep the synchronization with upstream easy no changes to the original files are allowed under dts/. Instead changes to upstream dts files will be done using overlays in arch/$ARCH/dts/. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Diffstat (limited to 'dts/Bindings/bus')
-rw-r--r--dts/Bindings/bus/imx-weim.txt82
-rw-r--r--dts/Bindings/bus/mvebu-mbus.txt276
-rw-r--r--dts/Bindings/bus/omap-ocp2scp.txt28
-rw-r--r--dts/Bindings/bus/ti-gpmc.txt130
4 files changed, 516 insertions, 0 deletions
diff --git a/dts/Bindings/bus/imx-weim.txt b/dts/Bindings/bus/imx-weim.txt
new file mode 100644
index 0000000000..6630d842c7
--- /dev/null
+++ b/dts/Bindings/bus/imx-weim.txt
@@ -0,0 +1,82 @@
+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.
+
+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 can get the CS index from 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@021b8000 {
+ 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>;
+ };
+ };
diff --git a/dts/Bindings/bus/mvebu-mbus.txt b/dts/Bindings/bus/mvebu-mbus.txt
new file mode 100644
index 0000000000..7586fb68c0
--- /dev/null
+++ b/dts/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,armada370-mbus
+ marvell,armadaxp-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 entries are expected (see the examples below):
+ the first one controls the devices decoding window and
+ the second one controls the SDRAM decoding window.
+
+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>;
+ };
+
+ /* 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>;
+ };
+
+ /* 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>;
+ };
+
+ /* 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
+choses 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 {
+ status = "okay";
+ 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";
+ status = "okay";
+ 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 */
+ status = "okay";
+ };
+ };
+
+ 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>;
+ };
+
+ interrupt-controller@20000 {
+ reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+ };
+ };
+ };
diff --git a/dts/Bindings/bus/omap-ocp2scp.txt b/dts/Bindings/bus/omap-ocp2scp.txt
new file mode 100644
index 0000000000..63dd805152
--- /dev/null
+++ b/dts/Bindings/bus/omap-ocp2scp.txt
@@ -0,0 +1,28 @@
+* OMAP OCP2SCP - ocp interface to scp interface
+
+properties:
+- compatible : Should be "ti,omap-ocp2scp"
+- 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/dts/Bindings/bus/ti-gpmc.txt b/dts/Bindings/bus/ti-gpmc.txt
new file mode 100644
index 0000000000..704be9306c
--- /dev/null
+++ b/dts/Bindings/bus/ti-gpmc.txt
@@ -0,0 +1,130 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible: Should be set to one of the following:
+
+ ti,omap2420-gpmc (omap2420)
+ ti,omap2430-gpmc (omap2430)
+ ti,omap3430-gpmc (omap3430 & omap3630)
+ ti,omap4430-gpmc (omap4430 & omap4460 & omap543x)
+ ti,am3352-gpmc (am335x devices)
+
+ - reg: A resource specifier for the register space
+ (see the example below)
+ - ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
+ completed.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells: Must be set to 1 to allow CS address passing
+ - gpmc,num-cs: The maximum number of chip-select lines that controller
+ can support.
+ - gpmc,num-waitpins: The maximum number of wait pins that controller can
+ support.
+ - 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>
+
+ Currently, calculated values derived from the contents
+ of the per-CS register GPMC_CONFIG7 (as set up by the
+ bootloader) are used for the physical address decoding.
+ As this will change in the future, filling correct
+ values here is a requirement.
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk-ps: Minimum clock period for synchronous mode, in picoseconds
+
+ Chip-select signal timings (in nanoseconds) corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on-ns: Assertion time
+ - gpmc,cs-rd-off-ns: Read deassertion time
+ - gpmc,cs-wr-off-ns: Write deassertion time
+
+ ADV signal timings (in nanoseconds) corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on-ns: Assertion time
+ - gpmc,adv-rd-off-ns: Read deassertion time
+ - gpmc,adv-wr-off-ns: Write deassertion time
+
+ WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
+ - gpmc,we-on-ns Assertion time
+ - gpmc,we-off-ns: Deassertion time
+
+ OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on-ns: Assertion time
+ - gpmc,oe-off-ns: Deassertion time
+
+ Access time and cycle time timings (in nanoseconds) corresponding to
+ GPMC_CONFIG5:
+ - gpmc,page-burst-access-ns: Multiple access word delay
+ - gpmc,access-ns: Start-cycle to first data valid delay
+ - gpmc,rd-cycle-ns: Total read cycle time
+ - gpmc,wr-cycle-ns: Total write cycle time
+ - gpmc,bus-turnaround-ns: Turn-around time between successive accesses
+ - gpmc,cycle2cycle-delay-ns: Delay between chip-select pulses
+ - gpmc,clk-activation-ns: GPMC clock activation time
+ - gpmc,wait-monitoring-ns: Start of wait monitoring with regard to valid
+ data
+
+Boolean timing parameters. If property is present parameter enabled and
+disabled if omitted:
+ - gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock
+ - gpmc,cs-extra-delay: CS signal is delayed by half GPMC clock
+ - gpmc,cycle2cycle-diffcsen: Add "cycle2cycle-delay" between successive
+ accesses to a different CS
+ - gpmc,cycle2cycle-samecsen: Add "cycle2cycle-delay" between successive
+ accesses to the same CS
+ - gpmc,oe-extra-delay: OE signal is delayed by half GPMC clock
+ - gpmc,we-extra-delay: WE signal is delayed by half GPMC clock
+ - gpmc,time-para-granularity: Multiply all access times by 2
+
+The following are only applicable to OMAP3+ and AM335x:
+ - gpmc,wr-access-ns: In synchronous write mode, for single or
+ burst accesses, defines the number of
+ GPMC_FCLK cycles from start access time
+ to the GPMC_CLK rising edge used by the
+ memory device for the first data capture.
+ - gpmc,wr-data-mux-bus-ns: In address-data multiplex mode, specifies
+ the time when the first data is driven on
+ the address-data bus.
+
+GPMC chip-select settings properties for child nodes. All are optional.
+
+- gpmc,burst-length Page/burst length. Must be 4, 8 or 16.
+- gpmc,burst-wrap Enables wrap bursting
+- gpmc,burst-read Enables read page/burst mode
+- gpmc,burst-write Enables write page/burst mode
+- gpmc,device-width Total width of device(s) connected to a GPMC
+ chip-select in bytes. The GPMC supports 8-bit
+ and 16-bit devices and so this property must be
+ 1 or 2.
+- gpmc,mux-add-data Address and data multiplexing configuration.
+ Valid values are 1 for address-address-data
+ multiplexing mode and 2 for address-data
+ multiplexing mode.
+- gpmc,sync-read Enables synchronous read. Defaults to asynchronous
+ is this is not set.
+- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous
+ is this is not set.
+- gpmc,wait-pin Wait-pin used by client. Must be less than
+ "gpmc,num-waitpins".
+- gpmc,wait-on-read Enables wait monitoring on reads.
+- gpmc,wait-on-write Enables wait monitoring on writes.
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ interrupts = <100>;
+
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
+
+ /* child nodes go here */
+ };