diff options
Diffstat (limited to 'Documentation/devicetree/bindings/reset')
-rw-r--r-- | Documentation/devicetree/bindings/reset/fsl,imx-src.txt | 49 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/reset/reset.txt | 75 |
2 files changed, 124 insertions, 0 deletions
diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt new file mode 100644 index 000000000000..13301777e11c --- /dev/null +++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt | |||
@@ -0,0 +1,49 @@ | |||
1 | Freescale i.MX System Reset Controller | ||
2 | ====================================== | ||
3 | |||
4 | Please also refer to reset.txt in this directory for common reset | ||
5 | controller binding usage. | ||
6 | |||
7 | Required properties: | ||
8 | - compatible: Should be "fsl,<chip>-src" | ||
9 | - reg: should be register base and length as documented in the | ||
10 | datasheet | ||
11 | - interrupts: Should contain SRC interrupt and CPU WDOG interrupt, | ||
12 | in this order. | ||
13 | - #reset-cells: 1, see below | ||
14 | |||
15 | example: | ||
16 | |||
17 | src: src@020d8000 { | ||
18 | compatible = "fsl,imx6q-src"; | ||
19 | reg = <0x020d8000 0x4000>; | ||
20 | interrupts = <0 91 0x04 0 96 0x04>; | ||
21 | #reset-cells = <1>; | ||
22 | }; | ||
23 | |||
24 | Specifying reset lines connected to IP modules | ||
25 | ============================================== | ||
26 | |||
27 | The system reset controller can be used to reset the GPU, VPU, | ||
28 | IPU, and OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device | ||
29 | nodes should specify the reset line on the SRC in their resets | ||
30 | property, containing a phandle to the SRC device node and a | ||
31 | RESET_INDEX specifying which module to reset, as described in | ||
32 | reset.txt | ||
33 | |||
34 | example: | ||
35 | |||
36 | ipu1: ipu@02400000 { | ||
37 | resets = <&src 2>; | ||
38 | }; | ||
39 | ipu2: ipu@02800000 { | ||
40 | resets = <&src 4>; | ||
41 | }; | ||
42 | |||
43 | The following RESET_INDEX values are valid for i.MX5: | ||
44 | GPU_RESET 0 | ||
45 | VPU_RESET 1 | ||
46 | IPU1_RESET 2 | ||
47 | OPEN_VG_RESET 3 | ||
48 | The following additional RESET_INDEX value is valid for i.MX6: | ||
49 | IPU2_RESET 4 | ||
diff --git a/Documentation/devicetree/bindings/reset/reset.txt b/Documentation/devicetree/bindings/reset/reset.txt new file mode 100644 index 000000000000..31db6ff84908 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/reset.txt | |||
@@ -0,0 +1,75 @@ | |||
1 | = Reset Signal Device Tree Bindings = | ||
2 | |||
3 | This binding is intended to represent the hardware reset signals present | ||
4 | internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole | ||
5 | standalone chips are most likely better represented as GPIOs, although there | ||
6 | are likely to be exceptions to this rule. | ||
7 | |||
8 | Hardware blocks typically receive a reset signal. This signal is generated by | ||
9 | a reset provider (e.g. power management or clock module) and received by a | ||
10 | reset consumer (the module being reset, or a module managing when a sub- | ||
11 | ordinate module is reset). This binding exists to represent the provider and | ||
12 | consumer, and provide a way to couple the two together. | ||
13 | |||
14 | A reset signal is represented by the phandle of the provider, plus a reset | ||
15 | specifier - a list of DT cells that represents the reset signal within the | ||
16 | provider. The length (number of cells) and semantics of the reset specifier | ||
17 | are dictated by the binding of the reset provider, although common schemes | ||
18 | are described below. | ||
19 | |||
20 | A word on where to place reset signal consumers in device tree: It is possible | ||
21 | in hardware for a reset signal to affect multiple logically separate HW blocks | ||
22 | at once. In this case, it would be unwise to represent this reset signal in | ||
23 | the DT node of each affected HW block, since if activated, an unrelated block | ||
24 | may be reset. Instead, reset signals should be represented in the DT node | ||
25 | where it makes most sense to control it; this may be a bus node if all | ||
26 | children of the bus are affected by the reset signal, or an individual HW | ||
27 | block node for dedicated reset signals. The intent of this binding is to give | ||
28 | appropriate software access to the reset signals in order to manage the HW, | ||
29 | rather than to slavishly enumerate the reset signal that affects each HW | ||
30 | block. | ||
31 | |||
32 | = Reset providers = | ||
33 | |||
34 | Required properties: | ||
35 | #reset-cells: Number of cells in a reset specifier; Typically 0 for nodes | ||
36 | with a single reset output and 1 for nodes with multiple | ||
37 | reset outputs. | ||
38 | |||
39 | For example: | ||
40 | |||
41 | rst: reset-controller { | ||
42 | #reset-cells = <1>; | ||
43 | }; | ||
44 | |||
45 | = Reset consumers = | ||
46 | |||
47 | Required properties: | ||
48 | resets: List of phandle and reset specifier pairs, one pair | ||
49 | for each reset signal that affects the device, or that the | ||
50 | device manages. Note: if the reset provider specifies '0' for | ||
51 | #reset-cells, then only the phandle portion of the pair will | ||
52 | appear. | ||
53 | |||
54 | Optional properties: | ||
55 | reset-names: List of reset signal name strings sorted in the same order as | ||
56 | the resets property. Consumers drivers will use reset-names to | ||
57 | match reset signal names with reset specifiers. | ||
58 | |||
59 | For example: | ||
60 | |||
61 | device { | ||
62 | resets = <&rst 20>; | ||
63 | reset-names = "reset"; | ||
64 | }; | ||
65 | |||
66 | This represents a device with a single reset signal named "reset". | ||
67 | |||
68 | bus { | ||
69 | resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>; | ||
70 | reset-names = "i2s1", "i2s2", "dma", "mixer"; | ||
71 | }; | ||
72 | |||
73 | This represents a bus that controls the reset signal of each of four sub- | ||
74 | ordinate devices. Consider for example a bus that fails to operate unless no | ||
75 | child device has reset asserted. | ||