89c1e2da78
A reset controller is a hardware module that controls reset signals that affect other hardware modules or chips. This patch defines a standard API that connects reset clients (i.e. the drivers for devices affected by reset signals) to drivers for reset controllers/providers. Initially, DT is the only supported method for connecting the two. The DT binding specification (reset.txt) was taken from Linux kernel v4.5's Documentation/devicetree/bindings/reset/reset.txt. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
76 lines
2.9 KiB
Plaintext
76 lines
2.9 KiB
Plaintext
= 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.
|