1= Reset Signal Device Tree Bindings = 2 3This binding is intended to represent the hardware reset signals present 4internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole 5standalone chips are most likely better represented as GPIOs, although there 6are likely to be exceptions to this rule. 7 8Hardware blocks typically receive a reset signal. This signal is generated by 9a reset provider (e.g. power management or clock module) and received by a 10reset consumer (the module being reset, or a module managing when a sub- 11ordinate module is reset). This binding exists to represent the provider and 12consumer, and provide a way to couple the two together. 13 14A reset signal is represented by the phandle of the provider, plus a reset 15specifier - a list of DT cells that represents the reset signal within the 16provider. The length (number of cells) and semantics of the reset specifier 17are dictated by the binding of the reset provider, although common schemes 18are described below. 19 20A word on where to place reset signal consumers in device tree: It is possible 21in hardware for a reset signal to affect multiple logically separate HW blocks 22at once. In this case, it would be unwise to represent this reset signal in 23the DT node of each affected HW block, since if activated, an unrelated block 24may be reset. Instead, reset signals should be represented in the DT node 25where it makes most sense to control it; this may be a bus node if all 26children of the bus are affected by the reset signal, or an individual HW 27block node for dedicated reset signals. The intent of this binding is to give 28appropriate software access to the reset signals in order to manage the HW, 29rather than to slavishly enumerate the reset signal that affects each HW 30block. 31 32= Reset providers = 33 34Required 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 39For example: 40 41 rst: reset-controller { 42 #reset-cells = <1>; 43 }; 44 45= Reset consumers = 46 47Required properties: 48resets: 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 54Optional properties: 55reset-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 59For example: 60 61 device { 62 resets = <&rst 20>; 63 reset-names = "reset"; 64 }; 65 66This 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 73This represents a bus that controls the reset signal of each of four sub- 74ordinate devices. Consider for example a bus that fails to operate unless no 75child device has reset asserted. 76