diff options
Diffstat (limited to 'roms/u-boot/doc/device-tree-bindings/reset')
4 files changed, 171 insertions, 0 deletions
diff --git a/roms/u-boot/doc/device-tree-bindings/reset/reset.txt b/roms/u-boot/doc/device-tree-bindings/reset/reset.txt new file mode 100644 index 000000000..31db6ff84 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/reset/reset.txt @@ -0,0 +1,75 @@ += 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. diff --git a/roms/u-boot/doc/device-tree-bindings/reset/st,stm32-rcc.txt b/roms/u-boot/doc/device-tree-bindings/reset/st,stm32-rcc.txt new file mode 100644 index 000000000..01db34375 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/reset/st,stm32-rcc.txt @@ -0,0 +1,6 @@ +STMicroelectronics STM32 Peripheral Reset Controller +==================================================== + +The RCC IP is both a reset and a clock controller. + +Please see Documentation/devicetree/bindings/clock/st,stm32-rcc.txt diff --git a/roms/u-boot/doc/device-tree-bindings/reset/syscon-reset.txt b/roms/u-boot/doc/device-tree-bindings/reset/syscon-reset.txt new file mode 100644 index 000000000..f136b3d22 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/reset/syscon-reset.txt @@ -0,0 +1,36 @@ +Generic SYSCON mapped register reset driver + +This is a generic reset driver using syscon to map the reset register. +The reset is generally performed with a write to the reset register +defined by the register map pointed by syscon reference plus the offset and +shifted by the reset specifier/ + +To assert a reset on some device, the equivalent of the following operation is +performed, where reset_id is the reset specifier from the device's resets +property. + + if (BIT(reset_id) & mask) + regmap[offset][reset_id] = assert-high; + +Required properties: +- compatible: should contain "syscon-reset" +- #reset-cells: must be 1 +- regmap: this is phandle to the register map node +- offset: offset in the register map for the reboot register (in bytes) + +Optional properties: +- mask: accept only the reset specifiers defined by the mask (32 bit) +- assert-high: Bit to write when asserting a reset. Defaults to 1. + +Default will be little endian mode, 32 bit access only. + +Example: + + reset-controller { + compatible = "syscon-reset"; + #reset-cells = <1>; + regmap = <&sysctl>; + offset = <0x20>; + mask = <0x27FFFFFF>; + assert-high = <0>; + }; diff --git a/roms/u-boot/doc/device-tree-bindings/reset/ti,sci-reset.txt b/roms/u-boot/doc/device-tree-bindings/reset/ti,sci-reset.txt new file mode 100644 index 000000000..e7e2d13f9 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/reset/ti,sci-reset.txt @@ -0,0 +1,54 @@ +Texas Instruments TI SCI Reset Controller +========================================= + +Some TI SoCs contain a system controller (like the SYSFW, etc...) that is +responsible for controlling the state of the IPs that are present. +Communication between the host processor running an OS and the system +controller happens through a protocol known as TI SCI [1]. + +[1] http://processors.wiki.ti.com/index.php/TISCI + +Reset Controller Node +===================== +The reset controller node represents the resets of various hardware modules +present on the SoC managed by the SYSFW. Because this relies on the TI SCI +protocol to communicate with the SYSFW it must be a child of the sysfw node. + +Required Properties: +-------------------- + - compatible: Must be "ti,sci-reset" + - #reset-cells: Must be 2. Please see the reset consumer node below for + usage details. + +Example (AM65x): +---------------- + sysfw: sysfw { + compatible = "ti,am654-system-controller"; + ... + k3_reset: reset-controller { + compatible = "ti,sci-reset"; + #reset-cells = <2>; + }; + }; + +Reset Consumers +=============== +Each of the reset consumer nodes should have the following properties, +in addition to their own properties. + +Required Properties: +-------------------- + - resets: A phandle and reset specifier pair, one pair for each reset signal + that affects the device, or that the device manages. The phandle + should point to the TI SCI reset controller node, and the reset + specifier should have 2 cell-values. The first cell should contain + the device ID. The second cell should contain the reset mask value + used by system controller. + +Example (AM65x): +---------------- + uart2: serial@02800000 { + compatible = "ti,omap4-uart"; + ... + resets = <&k3_reset 5 1>; + }; |