1 = Reset Signal Device Tree Bindings = 1 = Reset Signal Device Tree Bindings =
2 2
3 This binding is intended to represent the hard 3 This binding is intended to represent the hardware reset signals present
4 internally in most IC (SoC, FPGA, ...) designs 4 internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
5 standalone chips are most likely better repres 5 standalone chips are most likely better represented as GPIOs, although there
6 are likely to be exceptions to this rule. 6 are likely to be exceptions to this rule.
7 7
8 Hardware blocks typically receive a reset sign 8 Hardware blocks typically receive a reset signal. This signal is generated by
9 a reset provider (e.g. power management or clo 9 a reset provider (e.g. power management or clock module) and received by a
10 reset consumer (the module being reset, or a m 10 reset consumer (the module being reset, or a module managing when a sub-
11 ordinate module is reset). This binding exists 11 ordinate module is reset). This binding exists to represent the provider and
12 consumer, and provide a way to couple the two 12 consumer, and provide a way to couple the two together.
13 13
14 A reset signal is represented by the phandle o 14 A reset signal is represented by the phandle of the provider, plus a reset
15 specifier - a list of DT cells that represents 15 specifier - a list of DT cells that represents the reset signal within the
16 provider. The length (number of cells) and sem 16 provider. The length (number of cells) and semantics of the reset specifier
17 are dictated by the binding of the reset provi 17 are dictated by the binding of the reset provider, although common schemes
18 are described below. 18 are described below.
19 19
20 A word on where to place reset signal consumer 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 multi 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 r 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 i 23 the DT node of each affected HW block, since if activated, an unrelated block
24 may be reset. Instead, reset signals should be 24 may be reset. Instead, reset signals should be represented in the DT node
25 where it makes most sense to control it; this 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 26 children of the bus are affected by the reset signal, or an individual HW
27 block node for dedicated reset signals. The in 27 block node for dedicated reset signals. The intent of this binding is to give
28 appropriate software access to the reset signa 28 appropriate software access to the reset signals in order to manage the HW,
29 rather than to slavishly enumerate the reset s 29 rather than to slavishly enumerate the reset signal that affects each HW
30 block. 30 block.
31 31
32 = Reset providers = 32 = Reset providers =
33 33
34 Required properties: 34 Required properties:
35 #reset-cells: Number of cells in a reset spe 35 #reset-cells: Number of cells in a reset specifier; Typically 0 for nodes
36 with a single reset output and 36 with a single reset output and 1 for nodes with multiple
37 reset outputs. 37 reset outputs.
38 38
39 For example: 39 For example:
40 40
41 rst: reset-controller { 41 rst: reset-controller {
42 #reset-cells = <1>; 42 #reset-cells = <1>;
43 }; 43 };
44 44
45 = Reset consumers = 45 = Reset consumers =
46 46
47 Required properties: 47 Required properties:
48 resets: List of phandle and reset spec 48 resets: List of phandle and reset specifier pairs, one pair
49 for each reset signal that aff 49 for each reset signal that affects the device, or that the
50 device manages. Note: if the r 50 device manages. Note: if the reset provider specifies '0' for
51 #reset-cells, then only the ph 51 #reset-cells, then only the phandle portion of the pair will
52 appear. 52 appear.
53 53
54 Optional properties: 54 Optional properties:
55 reset-names: List of reset signal name stri 55 reset-names: List of reset signal name strings sorted in the same order as
56 the resets property. Consumers 56 the resets property. Consumers drivers will use reset-names to
57 match reset signal names with 57 match reset signal names with reset specifiers.
58 58
59 For example: 59 For example:
60 60
61 device { 61 device {
62 resets = <&rst 20>; 62 resets = <&rst 20>;
63 reset-names = "reset"; 63 reset-names = "reset";
64 }; 64 };
65 65
66 This represents a device with a single reset s 66 This represents a device with a single reset signal named "reset".
67 67
68 bus { 68 bus {
69 resets = <&rst 10> <&rst 11> < 69 resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;
70 reset-names = "i2s1", "i2s2", 70 reset-names = "i2s1", "i2s2", "dma", "mixer";
71 }; 71 };
72 72
73 This represents a bus that controls the reset 73 This represents a bus that controls the reset signal of each of four sub-
74 ordinate devices. Consider for example a bus t 74 ordinate devices. Consider for example a bus that fails to operate unless no
75 child device has reset asserted. 75 child device has reset asserted.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.