Stephen Warren | 89c1e2d | 2016-06-17 09:43:58 -0600 | [diff] [blame] | 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. |