summaryrefslogtreecommitdiffstats
path: root/Documentation/devicetree/bindings/soc/ti
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/devicetree/bindings/soc/ti')
-rw-r--r--Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml96
-rw-r--r--Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml40
-rw-r--r--Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt111
-rw-r--r--Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt238
-rw-r--r--Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt65
-rw-r--r--Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml439
-rw-r--r--Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt57
7 files changed, 1046 insertions, 0 deletions
diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
new file mode 100644
index 000000000..c3c595e23
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/ti/k3-ringacc.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Texas Instruments K3 NavigatorSS Ring Accelerator
+
+maintainers:
+ - Santosh Shilimkar <ssantosh@kernel.org>
+ - Grygorii Strashko <grygorii.strashko@ti.com>
+
+description: |
+ The Ring Accelerator (RA) is a machine which converts read/write accesses
+ from/to a constant address into corresponding read/write accesses from/to a
+ circular data structure in memory. The RA eliminates the need for each DMA
+ controller which needs to access ring elements from having to know the current
+ state of the ring (base address, current offset). The DMA controller
+ performs a read or write access to a specific address range (which maps to the
+ source interface on the RA) and the RA replaces the address for the transaction
+ with a new address which corresponds to the head or tail element of the ring
+ (head for reads, tail for writes).
+
+ The Ring Accelerator is a hardware module that is responsible for accelerating
+ management of the packet queues. The K3 SoCs can have more than one RA instances
+
+properties:
+ compatible:
+ items:
+ - const: ti,am654-navss-ringacc
+
+ reg:
+ items:
+ - description: real time registers regions
+ - description: fifos registers regions
+ - description: proxy gcfg registers regions
+ - description: proxy target registers regions
+
+ reg-names:
+ items:
+ - const: rt
+ - const: fifos
+ - const: proxy_gcfg
+ - const: proxy_target
+
+ msi-parent: true
+
+ ti,num-rings:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of rings supported by RA
+
+ ti,sci-rm-range-gp-rings:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TI-SCI RM subtype for GP ring range
+
+ ti,sci:
+ $ref: /schemas/types.yaml#definitions/phandle-array
+ description: phandle on TI-SCI compatible System controller node
+
+ ti,sci-dev-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TI-SCI device id of the ring accelerator
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,num-rings
+ - ti,sci-rm-range-gp-rings
+ - ti,sci
+ - ti,sci-dev-id
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ringacc: ringacc@3c000000 {
+ compatible = "ti,am654-navss-ringacc";
+ reg = <0x0 0x3c000000 0x0 0x400000>,
+ <0x0 0x38000000 0x0 0x400000>,
+ <0x0 0x31120000 0x0 0x100>,
+ <0x0 0x33000000 0x0 0x40000>;
+ reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target";
+ ti,num-rings = <818>;
+ ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <187>;
+ msi-parent = <&inta_main_udmass>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml b/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
new file mode 100644
index 000000000..a1a8423b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/k3-socinfo.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 Multicore SoC platforms chipid module
+
+maintainers:
+ - Tero Kristo <t-kristo@ti.com>
+ - Nishanth Menon <nm@ti.com>
+
+description: |
+ Texas Instruments (ARM64) K3 Multicore SoC platforms chipid module is
+ represented by CTRLMMR_xxx_JTAGID register which contains information about
+ SoC id and revision.
+
+properties:
+ $nodename:
+ pattern: "^chipid@[0-9a-f]+$"
+
+ compatible:
+ items:
+ - const: ti,am654-chipid
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ chipid@43000014 {
+ compatible = "ti,am654-chipid";
+ reg = <0x43000014 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt
new file mode 100644
index 000000000..337c4ea5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt
@@ -0,0 +1,111 @@
+Keystone Navigator DMA Controller
+
+This document explains the device tree bindings for the packet dma
+on keystone devices. The Keystone Navigator DMA driver sets up the dma
+channels and flows for the QMSS(Queue Manager SubSystem) who triggers
+the actual data movements across clients using destination queues. Every
+client modules like NETCP(Network Coprocessor), SRIO(Serial Rapid IO),
+CRYPTO Engines etc has its own instance of dma hardware. QMSS has also
+an internal packet DMA module which is used as an infrastructure DMA
+with zero copy.
+
+Navigator DMA cloud layout:
+ ------------------
+ | Navigator DMAs |
+ ------------------
+ |
+ |-> DMA instance #0
+ |
+ |-> DMA instance #1
+ .
+ .
+ |
+ |-> DMA instance #n
+
+Navigator DMA properties:
+Required properties:
+ - compatible: Should be "ti,keystone-navigator-dma"
+ - clocks: phandle to dma instances clocks. The clock handles can be as
+ many as the dma instances. The order should be maintained as per
+ the dma instances.
+ - ti,navigator-cloud-address: Should contain base address for the multi-core
+ navigator cloud and number of addresses depends on SOC integration
+ configuration.. Navigator cloud global address needs to be programmed
+ into DMA and the DMA uses it as the physical addresses to reach queue
+ managers. Note that these addresses though points to queue managers,
+ they are relevant only from DMA perspective. The QMSS may not choose to
+ use them since it has a different address space view to reach all
+ its components.
+
+DMA instance properties:
+Required properties:
+ - reg: Should contain register location and length of the following dma
+ register regions. Register regions should be specified in the following
+ order.
+ - Global control register region (global).
+ - Tx DMA channel configuration register region (txchan).
+ - Rx DMA channel configuration register region (rxchan).
+ - Tx DMA channel Scheduler configuration register region (txsched).
+ - Rx DMA flow configuration register region (rxflow).
+
+Optional properties:
+ - reg-names: Names for the register regions.
+ - ti,enable-all: Enable all DMA channels vs clients opening specific channels
+ what they need. This property is useful for the userspace fast path
+ case where the linux drivers enables the channels used by userland
+ stack.
+ - ti,loop-back: To loopback Tx streaming I/F to Rx streaming I/F. Used for
+ infrastructure transfers.
+ - ti,rx-retry-timeout: Number of dma cycles to wait before retry on buffer
+ starvation.
+
+Example:
+
+ knav_dmas: knav_dmas@0 {
+ compatible = "ti,keystone-navigator-dma";
+ clocks = <&papllclk>, <&clkxge>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,navigator-cloud-address = <0x23a80000 0x23a90000
+ 0x23aa0000 0x23ab0000>;
+
+ dma_gbe: dma_gbe@0 {
+ reg = <0x2004000 0x100>,
+ <0x2004400 0x120>,
+ <0x2004800 0x300>,
+ <0x2004c00 0x120>,
+ <0x2005000 0x400>;
+ reg-names = "global", "txchan", "rxchan",
+ "txsched", "rxflow";
+ };
+
+ dma_xgbe: dma_xgbe@0 {
+ reg = <0x2fa1000 0x100>,
+ <0x2fa1400 0x200>,
+ <0x2fa1800 0x200>,
+ <0x2fa1c00 0x200>,
+ <0x2fa2000 0x400>;
+ reg-names = "global", "txchan", "rxchan",
+ "txsched", "rxflow";
+ };
+ };
+
+Navigator DMA client:
+Required properties:
+ - ti,navigator-dmas: List of one or more DMA specifiers, each consisting of
+ - A phandle pointing to DMA instance node
+ - A DMA channel number as a phandle arg.
+ - ti,navigator-dma-names: Contains dma channel name for each DMA specifier in
+ the 'ti,navigator-dmas' property.
+
+Example:
+
+ netcp: netcp@2090000 {
+ ..
+ ti,navigator-dmas = <&dma_gbe 22>,
+ <&dma_gbe 23>,
+ <&dma_gbe 8>;
+ ti,navigator-dma-names = "netrx0", "netrx1", "nettx";
+ ..
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
new file mode 100644
index 000000000..b025770ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -0,0 +1,238 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+
+Required properties:
+- compatible : Must be "ti,keystone-navigator-qmss".
+ : Must be "ti,66ak2g-navss-qm" for QMSS on K2G SoC.
+- clocks : phandle to the reference clock for this device.
+- queue-range : <start number> total range of queue numbers for the device.
+- linkram0 : <address size> for internal link ram, where size is the total
+ link ram entries.
+- linkram1 : <address size> for external link ram, where size is the total
+ external link ram entries. If the address is specified as "0"
+ driver will allocate memory.
+- qmgrs : child node describing the individual queue managers on the
+ SoC. On keystone 1 devices there should be only one node.
+ On keystone 2 devices there can be more than 1 node.
+ -- managed-queues : the actual queues managed by each queue manager
+ instance, specified as <"base queue #" "# of queues">.
+ -- reg : Address and size of the register set for the device.
+ Register regions should be specified in the following
+ order
+ - Queue Peek region.
+ - Queue status RAM.
+ - Queue configuration region.
+ - Descriptor memory setup region.
+ - Queue Management/Queue Proxy region for queue Push.
+ - Queue Management/Queue Proxy region for queue Pop.
+
+For QMSS on K2G SoC, following QM reg indexes are used in that order
+ - Queue Peek region.
+ - Queue configuration region.
+ - Queue Management/Queue Proxy region for queue Push/Pop.
+
+- queue-pools : child node classifying the queue ranges into pools.
+ Queue ranges are grouped into 3 type of pools:
+ - qpend : pool of qpend(interruptible) queues
+ - general-purpose : pool of general queues, primarily used
+ as free descriptor queues or the
+ transmit DMA queues.
+ - accumulator : pool of queues on PDSP accumulator channel
+ Each range can have the following properties:
+ -- qrange : number of queues to use per queue range, specified as
+ <"base queue #" "# of queues">.
+ -- interrupts : Optional property to specify the interrupt mapping
+ for interruptible queues. The driver additionally sets
+ the interrupt affinity hint based on the cpu mask.
+ -- qalloc-by-id : Optional property to specify that the queues in this
+ range can only be allocated by queue id.
+ -- accumulator : Accumulator channel specification. Any of the PDSPs in
+ QMSS can be loaded with the accumulator firmware. The
+ accumulator firmware’s job is to poll a select number of
+ queues looking for descriptors that have been pushed
+ into them. Descriptors are popped from the queue and
+ placed in a buffer provided by the host. When the list
+ becomes full or a programmed time period expires, the
+ accumulator triggers an interrupt to the host to read
+ the buffer for descriptor information. This firmware
+ comes in 16, 32, and 48 channel builds. Each of these
+ channels can be configured to monitor 32 contiguous
+ queues. Accumulator channel property is specified as:
+ <pdsp-id, channel, entries, pacing mode, latency>
+ pdsp-id : QMSS PDSP running accumulator firmware
+ on which the channel has to be
+ configured
+ channel : Accumulator channel number
+ entries : Size of the accumulator descriptor list
+ pacing mode : Interrupt pacing mode
+ 0 : None, i.e interrupt on list full only
+ 1 : Time delay since last interrupt
+ 2 : Time delay since first new packet
+ 3 : Time delay since last new packet
+ latency : time to delay the interrupt, specified
+ in microseconds.
+ -- multi-queue : Optional property to specify that the channel has to
+ monitor up to 32 queues starting at the base queue #.
+- descriptor-regions : child node describing the memory regions for keystone
+ navigator packet DMA descriptors. The memory for
+ descriptors will be allocated by the driver.
+ -- id : region number in QMSS.
+ -- region-spec : specifies the number of descriptors in the
+ region, specified as
+ <"# of descriptors" "descriptor size">.
+ -- link-index : start index, i.e. index of the first
+ descriptor in the region.
+
+Optional properties:
+- dma-coherent : Present if DMA operations are coherent.
+- pdsps : child node describing the PDSP configuration.
+ -- firmware : firmware to be loaded on the PDSP.
+ -- id : the qmss pdsp that will run the firmware.
+ -- reg : Address and size of the register set for the PDSP.
+ Register regions should be specified in the following
+ order
+ - PDSP internal RAM region.
+ - PDSP control/status region registers.
+ - QMSS interrupt distributor registers.
+ - PDSP command interface region.
+
+Example:
+
+qmss: qmss@2a40000 {
+ compatible = "ti,keystone-qmss";
+ dma-coherent;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&chipclk13>;
+ ranges;
+ queue-range = <0 0x4000>;
+ linkram0 = <0x100000 0x8000>;
+ linkram1 = <0x0 0x10000>;
+
+ qmgrs {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ qmgr0 {
+ managed-queues = <0 0x2000>;
+ reg = <0x2a40000 0x20000>,
+ <0x2a06000 0x400>,
+ <0x2a02000 0x1000>,
+ <0x2a03000 0x1000>,
+ <0x23a80000 0x20000>,
+ <0x2a80000 0x20000>;
+ };
+
+ qmgr1 {
+ managed-queues = <0x2000 0x2000>;
+ reg = <0x2a60000 0x20000>,
+ <0x2a06400 0x400>,
+ <0x2a04000 0x1000>,
+ <0x2a05000 0x1000>,
+ <0x23aa0000 0x20000>,
+ <0x2aa0000 0x20000>;
+ };
+ };
+ queue-pools {
+ qpend {
+ qpend-0 {
+ qrange = <658 8>;
+ interrupts =<0 40 0xf04 0 41 0xf04 0 42 0xf04
+ 0 43 0xf04 0 44 0xf04 0 45 0xf04
+ 0 46 0xf04 0 47 0xf04>;
+ };
+ qpend-1 {
+ qrange = <8704 16>;
+ interrupts = <0 48 0xf04 0 49 0xf04 0 50 0xf04
+ 0 51 0xf04 0 52 0xf04 0 53 0xf04
+ 0 54 0xf04 0 55 0xf04 0 56 0xf04
+ 0 57 0xf04 0 58 0xf04 0 59 0xf04
+ 0 60 0xf04 0 61 0xf04 0 62 0xf04
+ 0 63 0xf04>;
+ qalloc-by-id;
+ };
+ qpend-2 {
+ qrange = <8720 16>;
+ interrupts = <0 64 0xf04 0 65 0xf04 0 66 0xf04
+ 0 59 0xf04 0 68 0xf04 0 69 0xf04
+ 0 70 0xf04 0 71 0xf04 0 72 0xf04
+ 0 73 0xf04 0 74 0xf04 0 75 0xf04
+ 0 76 0xf04 0 77 0xf04 0 78 0xf04
+ 0 79 0xf04>;
+ };
+ };
+ general-purpose {
+ gp-0 {
+ qrange = <4000 64>;
+ };
+ netcp-tx {
+ qrange = <640 9>;
+ qalloc-by-id;
+ };
+ };
+ accumulator {
+ acc-0 {
+ qrange = <128 32>;
+ accumulator = <0 36 16 2 50>;
+ interrupts = <0 215 0xf01>;
+ multi-queue;
+ qalloc-by-id;
+ };
+ acc-1 {
+ qrange = <160 32>;
+ accumulator = <0 37 16 2 50>;
+ interrupts = <0 216 0xf01>;
+ multi-queue;
+ };
+ acc-2 {
+ qrange = <192 32>;
+ accumulator = <0 38 16 2 50>;
+ interrupts = <0 217 0xf01>;
+ multi-queue;
+ };
+ acc-3 {
+ qrange = <224 32>;
+ accumulator = <0 39 16 2 50>;
+ interrupts = <0 218 0xf01>;
+ multi-queue;
+ };
+ };
+ };
+ descriptor-regions {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ region-12 {
+ id = <12>;
+ region-spec = <8192 128>; /* num_desc desc_size */
+ link-index = <0x4000>;
+ };
+ };
+ pdsps {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ pdsp0@2a10000 {
+ reg = <0x2a10000 0x1000>,
+ <0x2a0f000 0x100>,
+ <0x2a0c000 0x3c8>,
+ <0x2a20000 0x4000>;
+ id = <0>;
+ };
+ };
+}; /* qmss */
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
new file mode 100644
index 000000000..6217e6430
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
@@ -0,0 +1,65 @@
+Texas Instruments TI-SCI Generic Power Domain
+---------------------------------------------
+
+Some TI SoCs contain a system controller (like the PMMC, 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] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+PM Domain Node
+==============
+The PM domain node represents the global PM domain managed by the PMMC, which
+in this case is the implementation as documented by the generic PM domain
+bindings in Documentation/devicetree/bindings/power/power-domain.yaml. Because
+this relies on the TI SCI protocol to communicate with the PMMC it must be a
+child of the pmmc node.
+
+Required Properties:
+--------------------
+- compatible: should be "ti,sci-pm-domain"
+- #power-domain-cells: Can be one of the following:
+ 1: Containing the device id of each node
+ 2: First entry should be device id
+ Second entry should be one of the floowing:
+ TI_SCI_PD_EXCLUSIVE: To allow device to be
+ exclusively controlled by
+ the requesting hosts.
+ TI_SCI_PD_SHARED: To allow device to be shared
+ by multiple hosts.
+
+Example (K2G):
+-------------
+ pmmc: pmmc {
+ compatible = "ti,k2g-sci";
+ ...
+
+ k2g_pds: power-controller {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <1>;
+ };
+ };
+
+PM Domain Consumers
+===================
+Hardware blocks belonging to a PM domain should contain a "power-domains"
+property that is a phandle pointing to the corresponding PM domain node
+along with an index representing the device id to be passed to the PMMC
+for device control.
+
+Required Properties:
+--------------------
+- power-domains: phandle pointing to the corresponding PM domain node
+ and an ID representing the device.
+
+See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list
+of valid identifiers for k2g.
+
+Example (K2G):
+--------------------
+ uart0: serial@2530c00 {
+ compatible = "ns16550a";
+ ...
+ power-domains = <&k2g_pds 0x002c>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
new file mode 100644
index 000000000..037c51b2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
@@ -0,0 +1,439 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,pruss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: |+
+ TI Programmable Real-Time Unit and Industrial Communication Subsystem
+
+maintainers:
+ - Suman Anna <s-anna@ti.com>
+
+description: |+
+
+ The Programmable Real-Time Unit and Industrial Communication Subsystem
+ (PRU-ICSS a.k.a. PRUSS) is present on various TI SoCs such as AM335x, AM437x,
+ Keystone 66AK2G, OMAP-L138/DA850 etc. A PRUSS consists of dual 32-bit RISC
+ cores (Programmable Real-Time Units, or PRUs), shared RAM, data and
+ instruction RAMs, some internal peripheral modules to facilitate industrial
+ communication, and an interrupt controller.
+
+ The programmable nature of the PRUs provide flexibility to implement custom
+ peripheral interfaces, fast real-time responses, or specialized data handling.
+ The common peripheral modules include the following,
+ - an Ethernet MII_RT module with two MII ports
+ - an MDIO port to control external Ethernet PHYs
+ - an Industrial Ethernet Peripheral (IEP) to manage/generate Industrial
+ Ethernet functions
+ - an Enhanced Capture Module (eCAP)
+ - an Industrial Ethernet Timer with 7/9 capture and 16 compare events
+ - a 16550-compatible UART to support PROFIBUS
+ - Enhanced GPIO with async capture and serial support
+
+ A PRU-ICSS subsystem can have up to three shared data memories. A PRU core
+ acts on a primary Data RAM (there are usually 2 Data RAMs) at its address
+ 0x0, but also has access to a secondary Data RAM (primary to the other PRU
+ core) at its address 0x2000. A shared Data RAM, if present, can be accessed
+ by both the PRU cores. The Interrupt Controller (INTC) and a CFG module are
+ common to both the PRU cores. Each PRU core also has a private instruction
+ RAM, and specific register spaces for Control and Debug functionalities.
+
+ Various sub-modules within a PRU-ICSS subsystem are represented as individual
+ nodes and are defined using a parent-child hierarchy depending on their
+ integration within the IP and the SoC. These nodes are described in the
+ following sections.
+
+
+ PRU-ICSS Node
+ ==============
+ Each PRU-ICSS instance is represented as its own node with the individual PRU
+ processor cores, the memories node, an INTC node and an MDIO node represented
+ as child nodes within this PRUSS node. This node shall be a child of the
+ corresponding interconnect bus nodes or target-module nodes.
+
+ See ../../mfd/syscon.yaml for generic SysCon binding details.
+
+
+properties:
+ $nodename:
+ pattern: "^(pruss|icssg)@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - ti,am3356-pruss # for AM335x SoC family
+ - ti,am4376-pruss0 # for AM437x SoC family and PRUSS unit 0
+ - ti,am4376-pruss1 # for AM437x SoC family and PRUSS unit 1
+ - ti,am5728-pruss # for AM57xx SoC family
+ - ti,k2g-pruss # for 66AK2G SoC family
+ - ti,am654-icssg # for K3 AM65x SoC family
+ - ti,j721e-icssg # for K3 J721E SoC family
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges:
+ maxItems: 1
+
+ power-domains:
+ description: |
+ This property is as per sci-pm-domain.txt.
+
+patternProperties:
+
+ memories@[a-f0-9]+$:
+ description: |
+ The various Data RAMs within a single PRU-ICSS unit are represented as a
+ single node with the name 'memories'.
+
+ type: object
+
+ properties:
+ reg:
+ minItems: 2 # On AM437x one of two PRUSS units don't contain Shared RAM.
+ maxItems: 3
+ items:
+ - description: Address and size of the Data RAM0.
+ - description: Address and size of the Data RAM1.
+ - description: |
+ Address and size of the Shared Data RAM. Note that on AM437x one
+ of two PRUSS units don't contain Shared RAM, while the second one
+ has it.
+
+ reg-names:
+ minItems: 2
+ maxItems: 3
+ items:
+ - const: dram0
+ - const: dram1
+ - const: shrdram2
+
+ required:
+ - reg
+ - reg-names
+
+ additionalProperties: false
+
+ cfg@[a-f0-9]+$:
+ description: |
+ PRU-ICSS configuration space. CFG sub-module represented as a SysCon.
+
+ type: object
+
+ properties:
+ compatible:
+ items:
+ - const: ti,pruss-cfg
+ - const: syscon
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ ranges:
+ maxItems: 1
+
+ clocks:
+ type: object
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ coreclk-mux@[a-f0-9]+$:
+ description: |
+ This is applicable only for ICSSG (K3 SoCs). The ICSSG modules
+ core clock can be set to one of the 2 sources: ICSSG_CORE_CLK or
+ ICSSG_ICLK. This node models this clock mux and should have the
+ name "coreclk-mux".
+
+ type: object
+
+ properties:
+ '#clock-cells':
+ const: 0
+
+ clocks:
+ items:
+ - description: ICSSG_CORE Clock
+ - description: ICSSG_ICLK Clock
+
+ assigned-clocks:
+ maxItems: 1
+
+ assigned-clock-parents:
+ maxItems: 1
+ description: |
+ Standard assigned-clocks-parents definition used for selecting
+ mux parent (one of the mux input).
+
+ reg:
+ maxItems: 1
+
+ required:
+ - clocks
+
+ additionalProperties: false
+
+ iepclk-mux@[a-f0-9]+$:
+ description: |
+ The IEP module can get its clock from 2 sources: ICSSG_IEP_CLK or
+ CORE_CLK (OCP_CLK in older SoCs). This node models this clock
+ mux and should have the name "iepclk-mux".
+
+ type: object
+
+ properties:
+ '#clock-cells':
+ const: 0
+
+ clocks:
+ items:
+ - description: ICSSG_IEP Clock
+ - description: Core Clock (OCP Clock in older SoCs)
+
+ assigned-clocks:
+ maxItems: 1
+
+ assigned-clock-parents:
+ maxItems: 1
+ description: |
+ Standard assigned-clocks-parents definition used for selecting
+ mux parent (one of the mux input).
+
+ reg:
+ maxItems: 1
+
+ required:
+ - clocks
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ iep@[a-f0-9]+$:
+ description: |
+ Industrial Ethernet Peripheral to manage/generate Industrial Ethernet
+ functions such as time stamping. Each PRUSS has either 1 IEP (on AM335x,
+ AM437x, AM57xx & 66AK2G SoCs) or 2 IEPs (on K3 AM65x & J721E SoCs ). IEP
+ is used for creating PTP clocks and generating PPS signals.
+
+ type: object
+
+ mii-rt@[a-f0-9]+$:
+ description: |
+ Real-Time Ethernet to support multiple industrial communication protocols.
+ MII-RT sub-module represented as a SysCon.
+
+ type: object
+
+ properties:
+ compatible:
+ items:
+ - const: ti,pruss-mii
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ additionalProperties: false
+
+ mii-g-rt@[a-f0-9]+$:
+ description: |
+ The Real-time Media Independent Interface to support multiple industrial
+ communication protocols (G stands for Gigabit). MII-G-RT sub-module
+ represented as a SysCon.
+
+ type: object
+
+ properties:
+ compatible:
+ items:
+ - const: ti,pruss-mii-g
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ additionalProperties: false
+
+ interrupt-controller@[a-f0-9]+$:
+ description: |
+ PRUSS INTC Node. Each PRUSS has a single interrupt controller instance
+ that is common to all the PRU cores. This should be represented as an
+ interrupt-controller node.
+
+ type: object
+
+ mdio@[a-f0-9]+$:
+ description: |
+ MDIO Node. Each PRUSS has an MDIO module that can be used to control
+ external PHYs. The MDIO module used within the PRU-ICSS is an instance of
+ the MDIO Controller used in TI Davinci SoCs.
+
+ allOf:
+ - $ref: /schemas/net/ti,davinci-mdio.yaml#
+
+ type: object
+
+ "^(pru|rtu|txpru)@[0-9a-f]+$":
+ description: |
+ PRU Node. Each PRUSS has dual PRU cores, each represented as a RemoteProc
+ device through a PRU child node each. Each node can optionally be rendered
+ inactive by using the standard DT string property, "status". The ICSSG IP
+ present on K3 SoCs have additional auxiliary PRU cores with slightly
+ different IP integration.
+
+ type: object
+
+required:
+ - compatible
+ - reg
+ - ranges
+
+additionalProperties: false
+
+# Due to inability of correctly verifying sub-nodes with an @address through
+# the "required" list, the required sub-nodes below are commented out for now.
+
+#required:
+# - memories
+# - interrupt-controller
+# - pru
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,k2g-pruss
+ - ti,am654-icssg
+ - ti,j721e-icssg
+then:
+ required:
+ - power-domains
+
+examples:
+ - |
+
+ /* Example 1 AM33xx PRU-ICSS */
+ pruss: pruss@0 {
+ compatible = "ti,am3356-pruss";
+ reg = <0x0 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pruss_mem: memories@0 {
+ reg = <0x0 0x2000>,
+ <0x2000 0x2000>,
+ <0x10000 0x3000>;
+ reg-names = "dram0", "dram1", "shrdram2";
+ };
+
+ pruss_cfg: cfg@26000 {
+ compatible = "ti,pruss-cfg", "syscon";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x26000 0x2000>;
+ ranges = <0x00 0x26000 0x2000>;
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pruss_iepclk_mux: iepclk-mux@30 {
+ reg = <0x30>;
+ #clock-cells = <0>;
+ clocks = <&l3_gclk>, /* icss_iep */
+ <&pruss_ocp_gclk>; /* icss_ocp */
+ };
+ };
+ };
+
+ pruss_mii_rt: mii-rt@32000 {
+ compatible = "ti,pruss-mii", "syscon";
+ reg = <0x32000 0x58>;
+ };
+
+ pruss_mdio: mdio@32400 {
+ compatible = "ti,davinci_mdio";
+ reg = <0x32400 0x90>;
+ clocks = <&dpll_core_m4_ck>;
+ clock-names = "fck";
+ bus_freq = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ - |
+
+ /* Example 2 AM43xx PRU-ICSS with PRUSS1 node */
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pruss1: pruss@0 {
+ compatible = "ti,am4376-pruss1";
+ reg = <0x0 0x40000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pruss1_mem: memories@0 {
+ reg = <0x0 0x2000>,
+ <0x2000 0x2000>,
+ <0x10000 0x8000>;
+ reg-names = "dram0", "dram1", "shrdram2";
+ };
+
+ pruss1_cfg: cfg@26000 {
+ compatible = "ti,pruss-cfg", "syscon";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x26000 0x2000>;
+ ranges = <0x00 0x26000 0x2000>;
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pruss1_iepclk_mux: iepclk-mux@30 {
+ reg = <0x30>;
+ #clock-cells = <0>;
+ clocks = <&sysclk_div>, /* icss_iep */
+ <&pruss_ocp_gclk>; /* icss_ocp */
+ };
+ };
+ };
+
+ pruss1_mii_rt: mii-rt@32000 {
+ compatible = "ti,pruss-mii", "syscon";
+ reg = <0x32000 0x58>;
+ };
+
+ pruss1_mdio: mdio@32400 {
+ compatible = "ti,davinci_mdio";
+ reg = <0x32400 0x90>;
+ clocks = <&dpll_core_m4_ck>;
+ clock-names = "fck";
+ bus_freq = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
new file mode 100644
index 000000000..401550487
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
@@ -0,0 +1,57 @@
+Wakeup M3 IPC Driver
+=====================
+
+The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor
+(commonly referred to as Wakeup M3 or CM3) to help with various low power tasks
+that cannot be controlled from the MPU, like suspend/resume and certain deep
+C-states for CPU Idle. Once the wkup_m3_ipc driver uses the wkup_m3_rproc driver
+to boot the wkup_m3, it handles communication with the CM3 using IPC registers
+present in the SoC's control module and a mailbox. The wkup_m3_ipc exposes an
+API to allow the SoC PM code to execute specific PM tasks.
+
+Wkup M3 Device Node:
+====================
+A wkup_m3_ipc device node is used to represent the IPC registers within an
+SoC.
+
+Required properties:
+--------------------
+- compatible: Should be,
+ "ti,am3352-wkup-m3-ipc" for AM33xx SoCs
+ "ti,am4372-wkup-m3-ipc" for AM43xx SoCs
+- reg: Contains the IPC register address space to communicate
+ with the Wakeup M3 processor
+- interrupts: Contains the interrupt information for the wkup_m3
+ interrupt that signals the MPU.
+- ti,rproc: phandle to the wkup_m3 rproc node so the IPC driver
+ can boot it.
+- mboxes: phandles used by IPC framework to get correct mbox
+ channel for communication. Must point to appropriate
+ mbox_wkupm3 child node.
+
+Example:
+--------
+/* AM33xx */
+ l4_wkup: l4_wkup@44c00000 {
+ ...
+
+ scm: scm@210000 {
+ compatible = "ti,am3-scm", "simple-bus";
+ reg = <0x210000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x210000 0x2000>;
+
+ ...
+
+ wkup_m3_ipc: wkup_m3_ipc@1324 {
+ compatible = "ti,am3352-wkup-m3-ipc";
+ reg = <0x1324 0x24>;
+ interrupts = <78>;
+ ti,rproc = <&wkup_m3>;
+ mboxes = <&mailbox &mbox_wkupm3>;
+ };
+
+ ...
+ };
+ };