lastdragon/linux-kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resguardo inicial

Browse Source
This commit is contained in:
lastdragon
2026-09-06 12:53:21 -06:00
parent 662efe3c2a
commit ad2088d178
94853 changed files with 43200404 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
+96
View File
@@ -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
allOf:
- $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
properties:
compatible:
items:
- const: ti,am654-navss-ringacc
reg:
minItems: 4
items:
- description: real time registers regions
- description: fifos registers regions
- description: proxy gcfg registers regions
- description: proxy target registers regions
- description: configuration registers region
reg-names:
minItems: 4
items:
- const: rt
- const: fifos
- const: proxy_gcfg
- const: proxy_target
- const: cfg
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
required:
- compatible
- reg
- reg-names
- msi-parent
- ti,num-rings
- ti,sci-rm-range-gp-rings
- ti,sci
- ti,sci-dev-id
unevaluatedProperties: 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>,
<0x0 0x31080000 0x0 0x40000>;
reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
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>;
};
};
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt
+111
View File
@@ -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";
..
};
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+238
View File
@@ -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 */
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
+59
View File
@@ -0,0 +1,59 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI-SCI generic power domain
maintainers:
- Nishanth Menon <nm@ti.com>
allOf:
- $ref: /schemas/power/power-domain.yaml#
description: |
Some TI SoCs contain a system controller (like the Power Management Micro
Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
the state of the various hardware modules present on the SoC. Communication
between the host processor running an OS and the system controller happens
through a protocol called TI System Control Interface (TI-SCI protocol).
This PM domain node represents the global PM domain managed by the TI-SCI
controller. Since this relies on the TI SCI protocol to communicate with
the TI-SCI controller, it must be a child of the TI-SCI controller node.
properties:
compatible:
const: ti,sci-pm-domain
"#power-domain-cells":
enum: [1, 2]
description:
The two cells represent values that the TI-SCI controller defines.
The first cell should contain the device ID.
The second cell, if cell-value is 2, should be one of the following
TI_SCI_PD_EXCLUSIVE - Allows the device to be exclusively controlled
or
TI_SCI_PD_SHARED - Allows the device to be shared by multiple hosts.
Please refer to dt-bindings/soc/ti,sci_pm_domain.h for the definitions.
Please see https://software-dl.ti.com/tisci/esd/latest/index.html for
protocol documentation for the values to be used for different devices.
additionalProperties: false
examples:
- |
k2g_pds: power-controller {
compatible = "ti,sci-pm-domain";
#power-domain-cells = <1>;
};
- |
k3_pds: power-controller {
compatible = "ti,sci-pm-domain";
#power-domain-cells = <2>;
};
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/ti,am654-serdes-ctrl.yaml
+43
View File
@@ -0,0 +1,43 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/ti/ti,am654-serdes-ctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments AM654 Serdes Control Syscon
maintainers:
- Nishanth Menon <nm@ti.com>
properties:
compatible:
items:
- const: ti,am654-serdes-ctrl
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
mux-controller:
$ref: /schemas/mux/reg-mux.yaml#
required:
- compatible
- reg
- mux-controller
additionalProperties: false
examples:
- |
clock@4080 {
compatible = "ti,am654-serdes-ctrl", "syscon", "simple-mfd";
reg = <0x4080 0x4>;
mux-controller {
compatible = "mmio-mux";
#mux-control-cells = <1>;
mux-reg-masks = <0x0 0x3>; /* lane select */
};
};
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
+137
View File
@@ -0,0 +1,137 @@
# 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/ti,j721e-system-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI J721e System Controller Registers R/W
description: |
This represents the Control Module registers (CTRL_MMR0) on the SoC.
System controller node represents a register region containing a set
of miscellaneous registers. The registers are not cohesive enough to
represent as any specific type of device. The typical use-case is
for some other node's driver, or platform-specific code, to acquire
a reference to the syscon node (e.g. by phandle, node path, or
search using a specific compatible value), interrogate the node (or
associated OS driver) to determine the location of the registers,
and access the registers directly.
maintainers:
- Kishon Vijay Abraham I <kishon@kernel.org>
- Roger Quadros <rogerq@kernel.org>
properties:
compatible:
items:
- enum:
- ti,am654-system-controller
- ti,j7200-system-controller
- ti,j721e-system-controller
- ti,j721s2-system-controller
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 1
ranges: true
patternProperties:
# Optional children
"^mux-controller@[0-9a-f]+$":
type: object
description:
This is the SERDES lane control mux.
"^clock-controller@[0-9a-f]+$":
type: object
$ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
description:
Clock provider for TI EHRPWM nodes.
"phy@[0-9a-f]+$":
type: object
$ref: /schemas/phy/ti,phy-gmii-sel.yaml#
description:
The phy node corresponding to the ethernet MAC.
"^chipid@[0-9a-f]+$":
type: object
$ref: /schemas/hwinfo/ti,k3-socinfo.yaml#
description:
The node corresponding to SoC chip identification.
"^pcie-ctrl@[0-9a-f]+$":
type: object
description:
The node corresponding to PCIe control register.
"^clock@[0-9a-f]+$":
type: object
$ref: /schemas/soc/ti/ti,am654-serdes-ctrl.yaml#
description:
This is the Serdes Control region.
"^dss-oldi-io-ctrl@[0-9a-f]+$":
type: object
$ref: /schemas/mfd/syscon.yaml#
description:
This is the DSS OLDI CTRL region.
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties: false
examples:
- |
scm_conf: scm-conf@100000 {
compatible = "ti,j721e-system-controller", "syscon", "simple-mfd";
reg = <0x00100000 0x1c000>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
serdes_ln_ctrl: mux-controller@4080 {
compatible = "mmio-mux";
reg = <0x00004080 0x50>;
#mux-control-cells = <1>;
mux-reg-masks =
<0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */
<0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */
<0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */
<0x40b0 0x3>, <0x40b4 0x3>, /* SERDES3 lane0/1 select */
<0x40c0 0x3>, <0x40c4 0x3>, <0x40c8 0x3>, <0x40cc 0x3>;
/* SERDES4 lane0/1/2/3 select */
};
clock-controller@4140 {
compatible = "ti,am654-ehrpwm-tbclk";
reg = <0x4140 0x18>;
#clock-cells = <1>;
};
chipid@14 {
compatible = "ti,am654-chipid";
reg = <0x14 0x4>;
};
pcie0_ctrl: pcie-ctrl@4070 {
compatible = "ti,j784s4-pcie-ctrl", "syscon";
reg = <0x4070 0x4>;
};
};
...
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/ti,j784s4-bist.yaml
+63
View File
@@ -0,0 +1,63 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2025 Texas Instruments Incorporated
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/ti/ti,j784s4-bist.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 BIST
maintainers:
- Neha Malcom Francis <n-francis@ti.com>
allOf:
- $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
description:
The BIST (Built-In Self Test) module is an IP block present in K3 devices
that support triggering of BIST tests, both PBIST (Memory BIST) and LBIST
(Logic BIST) on a core. Both tests are destructive in nature. At boot, BIST
is executed by hardware for the MCU domain automatically as part of HW POST.
properties:
compatible:
const: ti,j784s4-bist
reg:
maxItems: 2
reg-names:
items:
- const: cfg
- const: ctrl_mmr
clocks:
maxItems: 1
power-domains:
maxItems: 1
required:
- compatible
- reg
- reg-names
- ti,sci-dev-id
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/soc/ti,sci_pm_domain.h>
bus {
#address-cells = <2>;
#size-cells = <2>;
safety-selftest@33c0000 {
compatible = "ti,j784s4-bist";
reg = <0x00 0x033c0000 0x00 0x400>,
<0x00 0x0010c1a0 0x00 0x01c>;
reg-names = "cfg", "ctrl_mmr";
clocks = <&k3_clks 237 7>;
power-domains = <&k3_pds 237 TI_SCI_PD_EXCLUSIVE>;
ti,sci-dev-id = <234>;
};
};
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/ti,omap-dmm.yaml
+53
View File
@@ -0,0 +1,53 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/ti/ti,omap-dmm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OMAP Dynamic Memory Manager (DMM)
maintainers:
- Bhargav Joshi <j.bhargav.u@gmail.com>
description:
The dynamic memory manager (DMM) is a module located immediately in front of
the SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of
memory accesses such as priority generation amongst initiators, configuration
of SDRAM interleaving, optimizing transfer of 2D block objects, and provide
MMU-like page translation for initiators which need contiguous dma bus
addresses.
properties:
compatible:
enum:
- ti,omap4-dmm
- ti,omap5-dmm
reg:
maxItems: 1
interrupts:
maxItems: 1
ti,hwmods:
$ref: /schemas/types.yaml#/definitions/string
description: Name of the hwmod associated to DMM, which is typically "dmm"
deprecated: true
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
dmm@4e000000 {
compatible = "ti,omap4-dmm";
reg = <0x4e000000 0x800>;
interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "dmm";
};
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
+557
View File
@@ -0,0 +1,557 @@
# 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,am625-pruss # for K3 AM62x SoC family
- ti,am642-icssg # for K3 AM64x SoC family
- ti,am654-icssg # for K3 AM65x SoC family
- ti,j721e-icssg # for K3 J721E SoC family
- ti,k2g-pruss # for 66AK2G SoC family
reg:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 1
ranges:
maxItems: 1
dma-ranges:
maxItems: 1
dma-coherent: true
power-domains:
description: |
This property is as per sci-pm-domain.txt.
clocks:
items:
- description: ICSSG_CORE Clock
- description: ICSSG_IEP Clock
- description: ICSSG_RGMII_MHZ_250 Clock
- description: ICSSG_RGMII_MHZ_50 Clock
- description: ICSSG_RGMII_MHZ_5 Clock
- description: ICSSG_UART Clock
- description: ICSSG_ICLK Clock
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.
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
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
additionalProperties: false
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 & AM64x SoCs).
IEP is used for creating PTP clocks and generating PPS signals.
type: object
ecap@[a-f0-9]+$:
description:
PRU-ICSS has a Enhanced Capture (eCAP) event module which can generate
and capture periodic timer based events which will be used for features
like RX Pacing to rise interrupt when the timer event has occurred.
Each PRU-ICSS instance has one eCAP module irrespective of SOCs.
$ref: /schemas/net/ti,pruss-ecap.yaml#
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
^pa-stats@[a-f0-9]+$:
description: |
PA-STATS sub-module represented as a SysCon. PA_STATS is a set of
registers where different statistics related to ICSSG, are dumped by
ICSSG firmware. This syscon sub-module will help the device to
access/read/write those statistics.
type: object
additionalProperties: false
properties:
compatible:
items:
- const: ti,pruss-pa-st
- const: syscon
reg:
maxItems: 1
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.
$ref: /schemas/interrupt-controller/ti,pruss-intc.yaml#
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.
$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.
$ref: /schemas/remoteproc/ti,pru-rproc.yaml#
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
allOf:
- if:
properties:
compatible:
contains:
enum:
- ti,k2g-pruss
- ti,am654-icssg
- ti,j721e-icssg
- ti,am642-icssg
then:
required:
- power-domains
- if:
properties:
compatible:
contains:
enum:
- ti,k2g-pruss
then:
required:
- dma-coherent
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_intc: interrupt-controller@20000 {
compatible = "ti,pruss-intc";
reg = <0x20000 0x2000>;
interrupt-controller;
#interrupt-cells = <3>;
interrupts = <20 21 22 23 24 25 26 27>;
interrupt-names = "host_intr0", "host_intr1",
"host_intr2", "host_intr3",
"host_intr4", "host_intr5",
"host_intr6", "host_intr7";
};
pru0: pru@34000 {
compatible = "ti,am3356-pru";
reg = <0x34000 0x2000>,
<0x22000 0x400>,
<0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am335x-pru0-fw";
};
pru1: pru@38000 {
compatible = "ti,am3356-pru";
reg = <0x38000 0x2000>,
<0x24000 0x400>,
<0x24400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am335x-pru1-fw";
};
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_intc: interrupt-controller@20000 {
compatible = "ti,pruss-intc";
reg = <0x20000 0x2000>;
interrupt-controller;
#interrupt-cells = <3>;
interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "host_intr0", "host_intr1",
"host_intr2", "host_intr3",
"host_intr4",
"host_intr6", "host_intr7";
ti,irqs-reserved = /bits/ 8 <0x20>; /* BIT(5) */
};
pru1_0: pru@34000 {
compatible = "ti,am4376-pru";
reg = <0x34000 0x3000>,
<0x22000 0x400>,
<0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am437x-pru1_0-fw";
};
pru1_1: pru@38000 {
compatible = "ti,am4376-pru";
reg = <0x38000 0x3000>,
<0x24000 0x400>,
<0x24400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am437x-pru1_1-fw";
};
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>;
};
};
...
linux-7.2.3/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml
+175
View File
@@ -0,0 +1,175 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/ti/wkup-m3-ipc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Wakeup M3 IPC device
maintainers:
- Dave Gerlach <d-gerlach@ti.com>
- Drew Fustini <dfustini@baylibre.com>
description: |+
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.
Support for VTT Toggle with GPIO pin
====================================
On some boards like the AM335x EVM-SK and the AM437x GP EVM, a GPIO pin is
connected to the enable pin on the DDR VTT regulator. This allows the
regulator to be disabled upon suspend and enabled upon resume. Please note
that the GPIO pin must be part of the GPIO0 module as only this GPIO module
is in the wakeup power domain.
Support for IO Isolation
========================
On AM437x SoCs, certain pins can be forced into an alternate state when IO
isolation is activated. Those pins have pad control registers prefixed by
'CTRL_CONF_' that contain DS0 (e.g. deep sleep) configuration bits that can
override the pin's existing bias (pull-up/pull-down) and value (high/low) when
IO isolation is active.
Support for I2C PMIC Voltage Scaling
====================================
It is possible to pass the name of a binary file to load into the CM3 memory.
The binary data is the I2C sequences for the CM3 to send out to the PMIC
during low power mode entry.
properties:
compatible:
enum:
- ti,am3352-wkup-m3-ipc # for AM33xx SoCs
- ti,am4372-wkup-m3-ipc # for AM43xx SoCs
reg:
description:
The IPC register address space to communicate with the Wakeup M3 processor
maxItems: 1
interrupts:
description: wkup_m3 interrupt that signals the MPU
maxItems: 1
ti,rproc:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to the wkup_m3 rproc node so the IPC driver can boot it
mboxes:
description:
phandles used by IPC framework to get correct mbox
channel for communication. Must point to appropriate
mbox_wkupm3 child node.
maxItems: 1
firmware-name:
description:
Name of binary file with I2C sequences for PMIC voltage scaling
ti,vtt-gpio-pin:
$ref: /schemas/types.yaml#/definitions/uint32
description: GPIO pin connected to enable pin on VTT regulator
ti,set-io-isolation:
type: boolean
description:
If this property is present, then the wkup_m3_ipc driver will instruct
the CM3 firmware to activate IO isolation when suspending to deep sleep.
This can be leveraged by a board design to put other devices on the board
into a low power state.
allOf:
- if:
properties:
compatible:
not:
contains:
const: ti,am4372-wkup-m3-ipc
then:
properties:
ti,set-io-isolation: false
required:
- compatible
- reg
- interrupts
- ti,rproc
- mboxes
additionalProperties: false
examples:
- |
/* Example for AM335x SoC */
soc {
#address-cells = <1>;
#size-cells = <1>;
am335x_mailbox: mailbox {
#mbox-cells = <1>;
};
wkup_m3_ipc@1324 {
compatible = "ti,am3352-wkup-m3-ipc";
reg = <0x1324 0x24>;
interrupts = <78>;
ti,rproc = <&wkup_m3>;
mboxes = <&am335x_mailbox &mbox_wkupm3>;
ti,vtt-gpio-pin = <7>;
firmware-name = "am335x-evm-scale-data.bin";
};
};
- |
/*
* Example for AM473x SoC:
* On the AM437x-GP-EVM board, gpio5_7 is wired to enable pin of the DDR VTT
* regulator. The 'ddr_vtt_toggle_default' pinmux node configures gpio5_7
* for pull-up during normal system operation. However, the DS0 (deep sleep)
* state of the pin is configured for pull-down and thus the VTT regulator
* will be disabled to save power when IO isolation is active. Note that
* this method is an alternative to using the 'ti,vtt-gpio-pin' property.
*/
#include <dt-bindings/pinctrl/am43xx.h>
soc {
#address-cells = <1>;
#size-cells = <1>;
am437x_mailbox: mailbox {
#mbox-cells = <1>;
};
am43xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&ddr3_vtt_toggle_default>;
ddr3_vtt_toggle_default: ddr_vtt_toggle_default {
pinctrl-single,pins = <
0x25C (DS0_PULL_UP_DOWN_EN | PIN_OUTPUT_PULLUP | DS0_FORCE_OFF_MODE | MUX_MODE7)
>;
};
};
wkup_m3_ipc@1324 {
compatible = "ti,am4372-wkup-m3-ipc";
reg = <0x1324 0x24>;
interrupts = <78>;
ti,rproc = <&wkup_m3>;
mboxes = <&am437x_mailbox &mbox_wkupm3>;
ti,set-io-isolation;
firmware-name = "am43x-evm-scale-data.bin";
};
};
...