diff options
Diffstat (limited to 'Documentation/devicetree/bindings')
15 files changed, 521 insertions, 53 deletions
diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt new file mode 100644 index 000000000000..7b9a861e9306 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt @@ -0,0 +1,20 @@ +System Control and Power Interface (SCPI) Message Protocol +(in addition to the standard binding in [0]) +---------------------------------------------------------- +Required properties + +- compatible : should be "amlogic,meson-gxbb-scpi" + +AMLOGIC SRAM and Shared Memory for SCPI +------------------------------------ + +Required properties: +- compatible : should be "amlogic,meson-gxbb-sram" + +Each sub-node represents the reserved area for SCPI. + +Required sub-node properties: +- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared + memory on Amlogic GXBB SoC. + +[0] Documentation/devicetree/bindings/arm/arm,scpi.txt diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index faa4b44572e3..401831973638 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -7,7 +7,10 @@ by Linux to initiate various system control and power operations. Required properties: -- compatible : should be "arm,scpi" +- compatible : should be + * "arm,scpi" : For implementations complying to SCPI v1.0 or above + * "arm,scpi-pre-1.0" : For implementations complying to all + unversioned releases prior to SCPI v1.0 - mboxes: List of phandle and mailbox channel specifiers All the channels reserved by remote SCP firmware for use by SCPI message protocol should be specified in any order @@ -59,18 +62,14 @@ SRAM and Shared Memory for SCPI A small area of SRAM is reserved for SCPI communication between application processors and SCP. -Required properties: -- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno - -The rest of the properties should follow the generic mmio-sram description -found in ../../sram/sram.txt +The properties should follow the generic mmio-sram description found in [3] Each sub-node represents the reserved area for SCPI. Required sub-node properties: - reg : The base offset and size of the reserved area with the SRAM -- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based - shared memory on Juno platforms +- compatible : should be "arm,scp-shmem" for Non-secure SRAM based + shared memory Sensor bindings for the sensors based on SCPI Message Protocol -------------------------------------------------------------- @@ -81,11 +80,9 @@ Required properties: - #thermal-sensor-cells: should be set to 1. This property follows the thermal device tree bindings[2]. - Valid cell values are raw identifiers (Sensor - ID) as used by the firmware. Refer to - platform documentation for your - implementation for the IDs to use. For Juno - R0 and Juno R1 refer to [3]. + Valid cell values are raw identifiers (Sensor ID) + as used by the firmware. Refer to platform details + for your implementation for the IDs to use. Power domain bindings for the power domains based on SCPI Message Protocol ------------------------------------------------------------ @@ -112,7 +109,7 @@ Required properties: [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/thermal/thermal.txt -[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html +[3] Documentation/devicetree/bindings/sram/sram.txt [4] Documentation/devicetree/bindings/power/power_domain.txt Example: diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt index e1f5ad855f14..29737b9b616e 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt @@ -225,3 +225,19 @@ required properties: compatible = "atmel,sama5d3-sfr", "syscon"; reg = <0xf0038000 0x60>; }; + +Security Module (SECUMOD) + +The Security Module macrocell provides all necessary secure functions to avoid +voltage, temperature, frequency and mechanical attacks on the chip. It also +embeds secure memories that can be scrambled + +required properties: +- compatible: Should be "atmel,<chip>-secumod", "syscon". + <chip> can be "sama5d2". +- reg: Should contain registers location and length + + secumod@fc040000 { + compatible = "atmel,sama5d2-secumod", "syscon"; + reg = <0xfc040000 0x100>; + }; diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt new file mode 100644 index 000000000000..2ace8696bbee --- /dev/null +++ b/Documentation/devicetree/bindings/arm/juno,scpi.txt @@ -0,0 +1,26 @@ +System Control and Power Interface (SCPI) Message Protocol +(in addition to the standard binding in [0]) + +Juno SRAM and Shared Memory for SCPI +------------------------------------ + +Required properties: +- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM + +Each sub-node represents the reserved area for SCPI. + +Required sub-node properties: +- reg : The base offset and size of the reserved area with the SRAM +- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based + shared memory on Juno platforms + +Sensor bindings for the sensors based on SCPI Message Protocol +-------------------------------------------------------------- +Required properties: +- compatible : should be "arm,scpi-sensors". +- #thermal-sensor-cells: should be set to 1. + For Juno R0 and Juno R1 refer to [1] for the + sensor identifiers + +[0] Documentation/devicetree/bindings/arm/arm,scpi.txt +[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt new file mode 100644 index 000000000000..31f5f9a104cc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt @@ -0,0 +1,81 @@ +Texas Instruments System Control Interface (TI-SCI) Message Protocol +-------------------------------------------------------------------- + +Texas Instrument's processors including those belonging to Keystone generation +of processors have separate hardware entity which is now responsible for the +management of the System on Chip (SoC) system. These include various system +level functions as well. + +An example of such an SoC is K2G, which contains the system control hardware +block called Power Management Micro Controller (PMMC). This hardware block is +initialized early into boot process and provides services to Operating Systems +on multiple processors including ones running Linux. + +See http://processors.wiki.ti.com/index.php/TISCI for protocol definition. + +TI-SCI controller Device Node: +============================= + +The TI-SCI node describes the Texas Instrument's System Controller entity node. +This parent node may optionally have additional children nodes which describe +specific functionality such as clocks, power domain, reset or additional +functionality as may be required for the SoC. This hierarchy also describes the +relationship between the TI-SCI parent node to the child node. + +Required properties: +------------------- +- compatible: should be "ti,k2g-sci" +- mbox-names: + "rx" - Mailbox corresponding to receive path + "tx" - Mailbox corresponding to transmit path + +- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes + property should contain a phandle to the mailbox controller device + node and an args specifier that will be the phandle to the intended + sub-mailbox child node to be used for communication. + +See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details +about the generic mailbox controller and client driver bindings. Also see +Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical +controller that is used to communicate with this System controllers. + +Optional Properties: +------------------- +- reg-names: + debug_messages - Map the Debug message region +- reg: register space corresponding to the debug_messages +- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot + +Example (K2G): +------------- + pmmc: pmmc { + compatible = "ti,k2g-sci"; + mbox-names = "rx", "tx"; + mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>, + <&msgmgr &msgmgr_proxy_pmmc_tx>; + reg-names = "debug_messages"; + reg = <0x02921800 0x800>; + }; + + +TI-SCI Client Device Node: +========================= + +Client nodes are maintained as children of the relevant TI-SCI device node. + +Example (K2G): +------------- + pmmc: pmmc { + compatible = "ti,k2g-sci"; + ... + + my_clk_node: clk_node { + ... + ... + }; + + my_pd_node: pd_node { + ... + ... + }; + }; diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index 5d8229d74a5f..253bf9b86690 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -85,3 +85,21 @@ Boards: compatible = "renesas,sk-rzg1m", "renesas,r8a7743" - Wheat compatible = "renesas,wheat", "renesas,r8a7792" + + +Most Renesas ARM SoCs have a Product Register that allows to retrieve SoC +product and revision information. If present, a device node for this register +should be added. + +Required properties: + - compatible: Must be "renesas,prr". + - reg: Base address and length of the register block. + + +Examples +-------- + + prr: chipid@ff000044 { + compatible = "renesas,prr"; + reg = <0 0xff000044 0 4>; + }; diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt new file mode 100644 index 000000000000..83b0e54f727c --- /dev/null +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt @@ -0,0 +1,132 @@ +Device tree bindings for NVIDIA Tegra Generic Memory Interface bus + +The Generic Memory Interface bus enables memory transfers between internal and +external memory. Can be used to attach various high speed devices such as +synchronous/asynchronous NOR, FPGA, UARTS and more. + +The actual devices are instantiated from the child nodes of a GMI node. + +Required properties: + - compatible : Should contain one of the following: + For Tegra20 must contain "nvidia,tegra20-gmi". + For Tegra30 must contain "nvidia,tegra30-gmi". + - reg: Should contain GMI controller registers location and length. + - clocks: Must contain an entry for each entry in clock-names. + - clock-names: Must include the following entries: "gmi" + - resets : Must contain an entry for each entry in reset-names. + - reset-names : Must include the following entries: "gmi" + - #address-cells: The number of cells used to represent physical base + addresses in the GMI address space. Should be 2. + - #size-cells: The number of cells used to represent the size of an address + range in the GMI address space. Should be 1. + - ranges: Must be set up to reflect the memory layout with three integer values + for each chip-select line in use (only one entry is supported, see below + comments): + <cs-number> <offset> <physical address of mapping> <size> + +Note that the GMI controller does not have any internal chip-select address +decoding, because of that chip-selects either need to be managed via software +or by employing external chip-select decoding logic. + +If external chip-select logic is used to support multiple devices it is assumed +that the devices use the same timing and so are probably the same type. It also +assumes that they can fit in the 256MB address range. In this case only one +child device is supported which represents the active chip-select line, see +examples for more insight. + +The chip-select number is decoded from the child nodes second address cell of +'ranges' property, if 'ranges' property is not present or empty chip-select will +then be decoded from the first cell of the 'reg' property. + +Optional child cs node properties: + + - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit. + - nvidia,snor-mux-mode: Enable address/data MUX mode. + - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data. + If omitted it will be asserted with data. + - nvidia,snor-rdy-active-high: RDY signal is active high + - nvidia,snor-adv-active-high: ADV signal is active high + - nvidia,snor-oe-active-high: WE/OE signal is active high + - nvidia,snor-cs-active-high: CS signal is active high + + Note that there is some special handling for the timing values. + From Tegra TRM: + Programming 0 means 1 clock cycle: actual cycle = programmed cycle + 1 + + - nvidia,snor-muxed-width: Number of cycles MUX address/data asserted on the + bus. Valid values are 0-15, default is 1 + - nvidia,snor-hold-width: Number of cycles CE stays asserted after the + de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N + (in case of MASTER Request). Valid values are 0-15, default is 1 + - nvidia,snor-adv-width: Number of cycles during which ADV stays asserted. + Valid values are 0-15, default is 1. + - nvidia,snor-ce-width: Number of cycles before CE is asserted. + Valid values are 0-15, default is 4 + - nvidia,snor-we-width: Number of cycles during which WE stays asserted. + Valid values are 0-15, default is 1 + - nvidia,snor-oe-width: Number of cycles during which OE stays asserted. + Valid values are 0-255, default is 1 + - nvidia,snor-wait-width: Number of cycles before READY is asserted. + Valid values are 0-255, default is 3 + +Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the +controllers with a simple-bus node since they are all connected to the same +chip-select (CS4), in this example external address decoding is provided: + +gmi@70090000 { + compatible = "nvidia,tegra20-gmi"; + reg = <0x70009000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + clocks = <&tegra_car TEGRA20_CLK_NOR>; + clock-names = "gmi"; + resets = <&tegra_car 42>; + reset-names = "gmi"; + ranges = <4 0 0xd0000000 0xfffffff>; + + status = "okay"; + + bus@4,0 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 4 0 0x40100>; + + nvidia,snor-mux-mode; + nvidia,snor-adv-active-high; + + can@0 { + reg = <0 0x100>; + ... + }; + + can@40000 { + reg = <0x40000 0x100>; + ... + }; + }; +}; + +Example with one SJA1000 CAN controller connected to the GMI bus +on CS4: + +gmi@70090000 { + compatible = "nvidia,tegra20-gmi"; + reg = <0x70009000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + clocks = <&tegra_car TEGRA20_CLK_NOR>; + clock-names = "gmi"; + resets = <&tegra_car 42>; + reset-names = "gmi"; + ranges = <4 0 0xd0000000 0xfffffff>; + + status = "okay"; + + can@4,0 { + reg = <4 0 0x100>; + nvidia,snor-mux-mode; + nvidia,snor-adv-active-high; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt new file mode 100644 index 000000000000..72daefc6b4a1 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt @@ -0,0 +1,20 @@ +* Device tree bindings for Texas Instruments da8xx master peripheral + priority driver + +DA8XX SoCs feature a set of registers allowing to change the priority of all +peripherals classified as masters. + +Documentation: +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf + +Required properties: + +- compatible: "ti,da850-mstpri" - for da850 based boards +- reg: offset and length of the mstpri registers + +Example for da850-lcdk is shown below. + +mstpri { + compatible = "ti,da850-mstpri"; + reg = <0x14110 0x0c>; +}; diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt new file mode 100644 index 000000000000..e821e16ad65b --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt @@ -0,0 +1,108 @@ +NVIDIA Tegra Boot and Power Management Processor (BPMP) + +The BPMP is a specific processor in Tegra chip, which is designed for +booting process handling and offloading the power management, clock +management, and reset control tasks from the CPU. The binding document +defines the resources that would be used by the BPMP firmware driver, +which can create the interprocessor communication (IPC) between the CPU +and BPMP. + +Required properties: +- name : Should be bpmp +- compatible + Array of strings + One of: + - "nvidia,tegra186-bpmp" +- mboxes : The phandle of mailbox controller and the mailbox specifier. +- shmem : List of the phandle of the TX and RX shared memory area that + the IPC between CPU and BPMP is based on. +- #clock-cells : Should be 1. +- #power-domain-cells : Should be 1. +- #reset-cells : Should be 1. + +This node is a mailbox consumer. See the following files for details of +the mailbox subsystem, and the specifiers implemented by the relevant +provider(s): + +- .../mailbox/mailbox.txt +- .../mailbox/nvidia,tegra186-hsp.txt + +This node is a clock, power domain, and reset provider. See the following +files for general documentation of those features, and the specifiers +implemented by this node: + +- .../clock/clock-bindings.txt +- <dt-bindings/clock/tegra186-clock.h> +- ../power/power_domain.txt +- <dt-bindings/power/tegra186-powergate.h> +- .../reset/reset.txt +- <dt-bindings/reset/tegra186-reset.h> + +The BPMP implements some services which must be represented by separate nodes. +For example, it can provide access to certain I2C controllers, and the I2C +bindings represent each I2C controller as a device tree node. Such nodes should +be nested directly inside the main BPMP node. + +Software can determine whether a child node of the BPMP node represents a device +by checking for a compatible property. Any node with a compatible property +represents a device that can be instantiated. Nodes without a compatible +property may be used to provide configuration information regarding the BPMP +itself, although no such configuration nodes are currently defined by this +binding. + +The BPMP firmware defines no single global name-/numbering-space for such +services. Put another way, the numbering scheme for I2C buses is distinct from +the numbering scheme for any other service the BPMP may provide (e.g. a future +hypothetical SPI bus service). As such, child device nodes will have no reg +property, and the BPMP node will have no #address-cells or #size-cells property. + +The shared memory bindings for BPMP +----------------------------------- + +The shared memory area for the IPC TX and RX between CPU and BPMP are +predefined and work on top of sysram, which is an SRAM inside the chip. + +See ".../sram/sram.txt" for the bindings. + +Example: + +hsp_top0: hsp@03c00000 { + ... + #mbox-cells = <2>; +}; + +sysram@30000000 { + compatible = "nvidia,tegra186-sysram", "mmio-sram"; + reg = <0x0 0x30000000 0x0 0x50000>; + #address-cells = <2>; + #size-cells = <2>; + ranges = <0 0x0 0x0 0x30000000 0x0 0x50000>; + + cpu_bpmp_tx: shmem@4e000 { + compatible = "nvidia,tegra186-bpmp-shmem"; + reg = <0x0 0x4e000 0x0 0x1000>; + label = "cpu-bpmp-tx"; + pool; + }; + + cpu_bpmp_rx: shmem@4f000 { + compatible = "nvidia,tegra186-bpmp-shmem"; + reg = <0x0 0x4f000 0x0 0x1000>; + label = "cpu-bpmp-rx"; + pool; + }; +}; + +bpmp { + compatible = "nvidia,tegra186-bpmp"; + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>; + shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>; + #clock-cells = <1>; + #power-domain-cells = <1>; + #reset-cells = <1>; + + i2c { + compatible = "..."; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index 3b4436e56865..20f26fbce875 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -10,8 +10,10 @@ Required properties: * "qcom,scm-apq8064" for APQ8064 platforms * "qcom,scm-msm8660" for MSM8660 platforms * "qcom,scm-msm8690" for MSM8690 platforms + * "qcom,scm-msm8996" for MSM8996 platforms * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc) - clocks: One to three clocks may be required based on compatible. + * No clock required for "qcom,scm-msm8996" * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960" * Core, iface, and bus clocks required for "qcom,scm" - clock-names: Must contain "core" for the core clock, "iface" for the interface diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt new file mode 100644 index 000000000000..b99d25fc2f26 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt @@ -0,0 +1,52 @@ +NVIDIA Tegra Hardware Synchronization Primitives (HSP) + +The HSP modules are used for the processors to share resources and communicate +together. It provides a set of hardware synchronization primitives for +interprocessor communication. So the interprocessor communication (IPC) +protocols can use hardware synchronization primitives, when operating between +two processors not in an SMP relationship. + +The features that HSP supported are shared mailboxes, shared semaphores, +arbitrated semaphores and doorbells. + +Required properties: +- name : Should be hsp +- compatible + Array of strings. + one of: + - "nvidia,tegra186-hsp" +- reg : Offset and length of the register set for the device. +- interrupt-names + Array of strings. + Contains a list of names for the interrupts described by the interrupt + property. May contain the following entries, in any order: + - "doorbell" + Users of this binding MUST look up entries in the interrupt property + by name, using this interrupt-names property to do so. +- interrupts + Array of interrupt specifiers. + Must contain one entry per entry in the interrupt-names property, + in a matching order. +- #mbox-cells : Should be 2. + +The mbox specifier of the "mboxes" property in the client node should +contain two data. The first one should be the HSP type and the second +one should be the ID that the client is going to use. Those information +can be found in the following file. + +- <dt-bindings/mailbox/tegra186-hsp.h>. + +Example: + +hsp_top0: hsp@3c00000 { + compatible = "nvidia,tegra186-hsp"; + reg = <0x0 0x03c00000 0x0 0xa0000>; + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "doorbell"; + #mbox-cells = <2>; +}; + +client { + ... + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_XXX>; +}; diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt new file mode 100644 index 000000000000..ec1dd408d573 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt @@ -0,0 +1,20 @@ +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller + +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs features +a set of registers which allow to tweak the controller's behavior. + +Documentation: +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf + +Required properties: + +- compatible: "ti,da850-ddr-controller" - for da850 SoC based boards +- reg: a tuple containing the base address of the memory + controller and the size of the memory area to map + +Example for da850 shown below. + +ddrctl { + compatible = "ti,da850-ddr-controller"; + reg = <0xb0000000 0xe8>; +}; diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt index 0725fb37a973..d91715bc8d52 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt @@ -1,12 +1,14 @@ -DT bindings for the Renesas R-Car System Controller +DT bindings for the Renesas R-Car (RZ/G) System Controller == System Controller Node == -The R-Car System Controller provides power management for the CPU cores and -various coprocessors. +The R-Car (RZ/G) System Controller provides power management for the CPU cores +and various coprocessors. Required properties: - compatible: Must contain exactly one of the following: + - "renesas,r8a7743-sysc" (RZ/G1M) + - "renesas,r8a7745-sysc" (RZ/G1E) - "renesas,r8a7779-sysc" (R-Car H1) - "renesas,r8a7790-sysc" (R-Car H2) - "renesas,r8a7791-sysc" (R-Car M2-W) diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt index 6f06db930030..d27ccb5d04fc 100644 --- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt +++ b/Documentation/devicetree/bindings/reset/oxnas,reset.txt @@ -5,45 +5,19 @@ Please also refer to reset.txt in this directory for common reset controller binding usage. Required properties: -- compatible: Should be "oxsemi,ox810se-reset" +- compatible: For OX810SE, should be "oxsemi,ox810se-reset" + For OX820, should be "oxsemi,ox820-reset" - #reset-cells: 1, see below Parent node should have the following properties : -- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd" +- compatible: For OX810SE, should be : + "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd" + For OX820, should be : + "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd" -For OX810SE, the indices are : - - 0 : ARM - - 1 : COPRO - - 2 : Reserved - - 3 : Reserved - - 4 : USBHS - - 5 : USBHSPHY - - 6 : MAC - - 7 : PCI - - 8 : DMA - - 9 : DPE - - 10 : DDR - - 11 : SATA - - 12 : SATA_LINK - - 13 : SATA_PHY - - 14 : Reserved - - 15 : NAND - - 16 : GPIO - - 17 : UART1 - - 18 : UART2 - - 19 : MISC - - 20 : I2S - - 21 : AHB_MON - - 22 : UART3 - - 23 : UART4 - - 24 : SGDMA - - 25 : Reserved - - 26 : Reserved - - 27 : Reserved - - 28 : Reserved - - 29 : Reserved - - 30 : Reserved - - 31 : BUS +Reset indices are in dt-bindings include files : +- For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h +- For OX820: include/dt-bindings/reset/oxsemi,ox820.h example: diff --git a/Documentation/devicetree/bindings/sram/sram.txt b/Documentation/devicetree/bindings/sram/sram.txt index add48f09015e..068c2c03c38f 100644 --- a/Documentation/devicetree/bindings/sram/sram.txt +++ b/Documentation/devicetree/bindings/sram/sram.txt @@ -4,7 +4,7 @@ Simple IO memory regions to be managed by the genalloc API. Required properties: -- compatible : mmio-sram +- compatible : mmio-sram or atmel,sama5d2-securam - reg : SRAM iomem address range |