mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
75 lines
2.9 KiB
75 lines
2.9 KiB
= Reset Signal Device Tree Bindings = |
|
|
|
This binding is intended to represent the hardware reset signals present |
|
internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole |
|
standalone chips are most likely better represented as GPIOs, although there |
|
are likely to be exceptions to this rule. |
|
|
|
Hardware blocks typically receive a reset signal. This signal is generated by |
|
a reset provider (e.g. power management or clock module) and received by a |
|
reset consumer (the module being reset, or a module managing when a sub- |
|
ordinate module is reset). This binding exists to represent the provider and |
|
consumer, and provide a way to couple the two together. |
|
|
|
A reset signal is represented by the phandle of the provider, plus a reset |
|
specifier - a list of DT cells that represents the reset signal within the |
|
provider. The length (number of cells) and semantics of the reset specifier |
|
are dictated by the binding of the reset provider, although common schemes |
|
are described below. |
|
|
|
A word on where to place reset signal consumers in device tree: It is possible |
|
in hardware for a reset signal to affect multiple logically separate HW blocks |
|
at once. In this case, it would be unwise to represent this reset signal in |
|
the DT node of each affected HW block, since if activated, an unrelated block |
|
may be reset. Instead, reset signals should be represented in the DT node |
|
where it makes most sense to control it; this may be a bus node if all |
|
children of the bus are affected by the reset signal, or an individual HW |
|
block node for dedicated reset signals. The intent of this binding is to give |
|
appropriate software access to the reset signals in order to manage the HW, |
|
rather than to slavishly enumerate the reset signal that affects each HW |
|
block. |
|
|
|
= Reset providers = |
|
|
|
Required properties: |
|
#reset-cells: Number of cells in a reset specifier; Typically 0 for nodes |
|
with a single reset output and 1 for nodes with multiple |
|
reset outputs. |
|
|
|
For example: |
|
|
|
rst: reset-controller { |
|
#reset-cells = <1>; |
|
}; |
|
|
|
= Reset consumers = |
|
|
|
Required properties: |
|
resets: List of phandle and reset specifier pairs, one pair |
|
for each reset signal that affects the device, or that the |
|
device manages. Note: if the reset provider specifies '0' for |
|
#reset-cells, then only the phandle portion of the pair will |
|
appear. |
|
|
|
Optional properties: |
|
reset-names: List of reset signal name strings sorted in the same order as |
|
the resets property. Consumers drivers will use reset-names to |
|
match reset signal names with reset specifiers. |
|
|
|
For example: |
|
|
|
device { |
|
resets = <&rst 20>; |
|
reset-names = "reset"; |
|
}; |
|
|
|
This represents a device with a single reset signal named "reset". |
|
|
|
bus { |
|
resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>; |
|
reset-names = "i2s1", "i2s2", "dma", "mixer"; |
|
}; |
|
|
|
This represents a bus that controls the reset signal of each of four sub- |
|
ordinate devices. Consider for example a bus that fails to operate unless no |
|
child device has reset asserted.
|
|
|