diff options
86 files changed, 11428 insertions, 722 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"; + |