Based on kernel version 6.11
. Page generated on 2024-09-24 08:21 EST
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 | # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright (C) 2019 Texas Instruments Incorporated # Author: Peter Ujfalusi <peter.ujfalusi@ti.com> %YAML 1.2 --- $id: http://devicetree.org/schemas/dma/ti/k3-udma.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K3 NAVSS Unified DMA maintainers: - Peter Ujfalusi <peter.ujfalusi@gmail.com> description: | The UDMA-P is intended to perform similar (but significantly upgraded) functions as the packet-oriented DMA used on previous SoC devices. The UDMA-P module supports the transmission and reception of various packet types. The UDMA-P architecture facilitates the segmentation and reassembly of SoC DMA data structure compliant packets to/from smaller data blocks that are natively compatible with the specific requirements of each connected peripheral. Multiple Tx and Rx channels are provided within the DMA which allow multiple segmentation or reassembly operations to be ongoing. The DMA controller maintains state information for each of the channels which allows packet segmentation and reassembly operations to be time division multiplexed between channels in order to share the underlying DMA hardware. An external DMA scheduler is used to control the ordering and rate at which this multiplexing occurs for Transmit operations. The ordering and rate of Receive operations is indirectly controlled by the order in which blocks are pushed into the DMA on the Rx PSI-L interface. The UDMA-P also supports acting as both a UTC and UDMA-C for its internal channels. Channels in the UDMA-P can be configured to be either Packet-Based or Third-Party channels on a channel by channel basis. All transfers within NAVSS is done between PSI-L source and destination threads. The peripherals serviced by UDMA can be PSI-L native (sa2ul, cpsw, etc) or legacy, non PSI-L native peripherals. In the later case a special, small PDMA is tasked to act as a bridge between the PSI-L fabric and the legacy peripheral. PDMAs can be configured via UDMAP peer registers to match with the configuration of the legacy peripheral. allOf: - $ref: ../dma-controller.yaml# - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# properties: "#dma-cells": minimum: 1 maximum: 2 description: | The cell is the PSI-L thread ID of the remote (to UDMAP) end. Valid ranges for thread ID depends on the data movement direction: for source thread IDs (rx): 0 - 0x7fff for destination thread IDs (tx): 0x8000 - 0xffff Please refer to the device documentation for the PSI-L thread map and also the PSI-L peripheral chapter for the correct thread ID. When #dma-cells is 2, the second parameter is the channel ATYPE. compatible: enum: - ti,am654-navss-main-udmap - ti,am654-navss-mcu-udmap - ti,j721e-navss-main-udmap - ti,j721e-navss-mcu-udmap reg: minItems: 3 items: - description: UDMA-P Control /Status Registers region - description: RX Channel Realtime Registers region - description: TX Channel Realtime Registers region - description: TX Configuration Registers region - description: RX Configuration Registers region - description: RX Flow Configuration Registers region reg-names: minItems: 3 items: - const: gcfg - const: rchanrt - const: tchanrt - const: tchan - const: rchan - const: rflow msi-parent: true ti,ringacc: description: phandle to the ring accelerator node $ref: /schemas/types.yaml#/definitions/phandle ti,sci-rm-range-tchan: description: | Array of UDMA tchan resource subtypes for resource allocation for this host $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 # Should be enough maxItems: 255 ti,sci-rm-range-rchan: description: | Array of UDMA rchan resource subtypes for resource allocation for this host $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 # Should be enough maxItems: 255 ti,sci-rm-range-rflow: description: | Array of UDMA rflow resource subtypes for resource allocation for this host $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 # Should be enough maxItems: 255 required: - compatible - "#dma-cells" - reg - reg-names - msi-parent - ti,sci - ti,sci-dev-id - ti,ringacc - ti,sci-rm-range-tchan - ti,sci-rm-range-rchan - ti,sci-rm-range-rflow if: properties: "#dma-cells": const: 2 then: properties: ti,udma-atype: description: ATYPE value which should be used by non slave channels $ref: /schemas/types.yaml#/definitions/uint32 required: - ti,udma-atype unevaluatedProperties: false examples: - |+ cbass_main { #address-cells = <2>; #size-cells = <2>; cbass_main_navss: navss@30800000 { compatible = "simple-mfd"; #address-cells = <2>; #size-cells = <2>; dma-coherent; dma-ranges; ranges = <0x0 0x30800000 0x0 0x30800000 0x0 0x05000000>; ti,sci-dev-id = <118>; main_udmap: dma-controller@31150000 { compatible = "ti,am654-navss-main-udmap"; reg = <0x0 0x31150000 0x0 0x100>, <0x0 0x34000000 0x0 0x100000>, <0x0 0x35000000 0x0 0x100000>, <0x0 0x30b00000 0x0 0x20000>, <0x0 0x30c00000 0x0 0x8000>, <0x0 0x30d00000 0x0 0x4000>; reg-names = "gcfg", "rchanrt", "tchanrt", "tchan", "rchan", "rflow"; #dma-cells = <1>; ti,ringacc = <&ringacc>; msi-parent = <&inta_main_udmass>; ti,sci = <&dmsc>; ti,sci-dev-id = <188>; ti,sci-rm-range-tchan = <0x1>, /* TX_HCHAN */ <0x2>; /* TX_CHAN */ ti,sci-rm-range-rchan = <0x4>, /* RX_HCHAN */ <0x5>; /* RX_CHAN */ ti,sci-rm-range-rflow = <0x6>; /* GP RFLOW */ }; }; }; |