aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64/boot/dts/ti
Commit message (Collapse)AuthorAgeFilesLines
* arm64: dts: ti: k3-j721s2-common-proc-board: Alias console uart to serial2Aswath Govindraju2022-01-241-3/+3
| | | | | | | | | | | | On J721s2 Linux console is on main_uart8 but to be consistent with other J7 family of devices, alias it to ttyS2 (serial2). This also eliminates need to have higher number of 8250 runtime UARTs. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20211223121650.26868-3-vigneshr@ti.com
* arm64: dts: ti: k3-j721s2: Move aliases to board dtsAswath Govindraju2022-01-242-22/+10
| | | | | | | | | | | | Aliases are board specific and should be in board dts files. So, move aliases to board dts and trim the list to interfaces that are actually enabled. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20211223121650.26868-2-vigneshr@ti.com
* arch: arm64: ti: Add support J721S2 Common Processor BoardAswath Govindraju2021-12-132-0/+423
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EVM architecture for J721S2 is similar to that of J721E and J7200. It is as follows, +------------------------------------------------------+ | +-------------------------------------------+ | | | | | | | Add-on Card 1 Options | | | | | | | +-------------------------------------------+ | | | | | | +-------------------+ | | | | | | | SOM | | | +--------------+ | | | | | | | | | | | Add-on | +-------------------+ | | | Card 2 | | Power Supply | | Options | | | | | | | | | +--------------+ | <--- +------------------------------------------------------+ Common Processor Board Common Processor board is the baseboard that contains most of the actual connectors, power supply etc. The System on Module (SoM) is plugged on to the common processor baord. Therefore, add support for peripherals brought out in the common processor board. Common Processor Board: https://www.ti.com/tool/J721EXCPXEVM Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20211207080904.14324-6-a-govindraju@ti.com
* arm64: dts: ti: Add initial support for J721S2 System on ModuleAswath Govindraju2021-12-131-0/+175
| | | | | | | | | | | | | A System on Module (SoM) contains the SoC, PMIC, DDR and basic high speed components necessary for functionality. Therefore, add support for the components present on the SoM. SoM: https://www.ti.com/lit/zip/sprr439 Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20211207080904.14324-5-a-govindraju@ti.com
* arm64: dts: ti: Add initial support for J721S2 SoCAswath Govindraju2021-12-133-0/+1428
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The J721S2 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration in automotive ADAS applications and industrial applications requiring AI at the network edge. This SoC extends the Jacinto 7 family of SoCs with focus on lowering system costs and power while providing interfaces, memory architecture and compute performance for single and multi-sensor applications. Some highlights of this SoC are: * Dual Cortex-A72s in a single cluster, three clusters of lockstep capable dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA), C7x floating point Vector DSP. * 3D GPU: Automotive grade IMG BXS-4-64 * Vision Processing Accelerator (VPAC) with image signal processor and Depth and Motion Processing Accelerator (DMPAC) * Two CSI2.0 4L RX plus one eDP/DP, two DSI Tx, and one DPI interface. * Two Ethernet ports with RGMII support. * Single 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems, * Up to 20 MCANs, 5 McASP, eMMC and SD, OSPI/HyperBus memory controller, QSPI, I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals. * Hardware accelerator blocks containing AES/DES/SHA/MD5 called SA2UL management. * Chips and Media Wave521CL H.264/H.265 encode/decode engine See J721S2 Technical Reference Manual (SPRUJ28 – NOVEMBER 2021) for further details: http://www.ti.com/lit/pdf/spruj28 Introduce basic support for the J721S2 SoC. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20211207080904.14324-4-a-govindraju@ti.com
* arm64: dts: ti: iot2050: Disable mcasp nodes at dtsi levelJayesh Choudhary2021-12-131-0/+12
| | | | | | | | | | | Disable mcasp nodes 0-2 because several required properties are not present in the dtsi file as they are board specific. These nodes can be enabled via an overlay whenever required. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Acked-by: Jan Kiszka <jan.kiszka@siemens.com> Link: https://lore.kernel.org/r/20211117053806.10095-1-j-choudhary@ti.com
* arm64: dts: ti: k3-am642-evm/sk: Add support for main domain mcan nodes in ↵Aswath Govindraju2021-12-072-0/+48
| | | | | | | | | | | | | | | | | EVM and disable them on SK AM642 EVM has two CAN connecters brought out from the two MCAN instances in the main domain through transceivers. Add device tree nodes for transceivers and set the required properties in the mcan device tree nodes, in EVM device tree file. On AM642 SK there are no connectors brought out for CAN. Therefore, disable the mcan device tree nodes in the SK device tree file. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-7-a-govindraju@ti.com
* arm64: dts: ti: k3-am64-main: Add support for MCANAswath Govindraju2021-12-071-0/+28
| | | | | | | | | | Add Support for two MCAN controllers present on the am64x SOC. Both support classic CAN messages as well as CAN-FD. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-6-a-govindraju@ti.com
* arm64: dts: ti: k3-j721e-common-proc-board: Add support for mcu and main ↵Faiz Abbas2021-12-071-0/+155
| | | | | | | | | | | | | | mcan nodes Add four MCAN nodes present on the common processor board and set a maximum data rate of 5 Mbps. Disable all other nodes as they are not brought out on the common processor board. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-5-a-govindraju@ti.com
* arm64: dts: ti: k3-j721e: Add support for MCAN nodesFaiz Abbas2021-12-072-0/+224
| | | | | | | | | | | | Add support for 14 MCAN controllers in main domain and 2 MCAN controllers present in mcu domain. All the MCAN controllers support classic CAN messages as well as CAN_FD messages. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-4-a-govindraju@ti.com
* arm64: dts: ti: am654-base-board/am65-iot2050-common: Disable mcan nodesAswath Govindraju2021-12-072-0/+16
| | | | | | | | | | AM654 base board and iot platforms do not have mcan instances pinned out. Therefore, disable all the mcan instances. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-3-a-govindraju@ti.com
* arm64: dts: ti: k3-am65-mcu: Add Support for MCANFaiz Abbas2021-12-071-0/+30
| | | | | | | | | | | Add Support for two MCAN controllers present on the am65x SOC. Both support classic CAN messages as well as CAN-FD. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-2-a-govindraju@ti.com
* arm64: dts: ti: k3-am64-main: add timesync router nodeChristian Gmeiner2021-12-031-0/+8
| | | | | | | | | | | | | | The Time Sync Event Router (TIMESYNC_INTRTR0) implements a set of multiplexers to provide selection of active CPTS time sync events for routing to CPTS capable modules. This patch adds DT node TIMESYNC_INTRTR0 using "pinctrl-single" bindings. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20211202173114.9936-1-christian.gmeiner@gmail.com
* arm64: dts: ti: k3-j7200: Correct the d-cache-sets infoNishanth Menon2021-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | A72 Cluster (chapter 1.3.1 [1]) has 48KB Icache, 32KB Dcache and 1MB L2 Cache - ICache is 3-way set-associative - Dcache is 2-way set-associative - Line size are 64bytes 32KB (Dcache)/64 (fixed line length of 64 bytes) = 512 ways 512 ways / 2 (Dcache is 2-way per set) = 256 sets. So, correct the d-cache-sets info. [1] https://www.ti.com/lit/pdf/spruiu1 Fixes: d361ed88455f ("arm64: dts: ti: Add support for J7200 SoC") Reported-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211113042640.30955-1-nm@ti.com
* arm64: dts: ti: k3-j721e: Fix the L2 cache setsNishanth Menon2021-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | A72's L2 cache[1] on J721e[2] is 1MB. A72's L2 is fixed line length of 64 bytes and 16-way set-associative cache structure. 1MB of L2 / 64 (line length) = 16384 ways 16384 ways / 16 = 1024 sets Fix the l2 cache-sets. [1] https://developer.arm.com/documentation/100095/0003/Level-2-Memory-System/About-the-L2-memory-system [2] http://www.ti.com/lit/pdf/spruil1 Fixes: 2d87061e70de ("arm64: dts: ti: Add Support for J721E SoC") Reported-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211113043639.4413-1-nm@ti.com
* arm64: dts: ti: k3-j7200: Fix the L2 cache setsNishanth Menon2021-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | A72's L2 cache[1] on J7200[2] is 1MB. A72's L2 is fixed line length of 64 bytes and 16-way set-associative cache structure. 1MB of L2 / 64 (line length) = 16384 ways 16384 ways / 16 = 1024 sets Fix the l2 cache-sets. [1] https://developer.arm.com/documentation/100095/0003/Level-2-Memory-System/About-the-L2-memory-system [2] https://www.ti.com/lit/pdf/spruiu1 Fixes: d361ed88455f ("arm64: dts: ti: Add support for J7200 SoC") Reported-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211113043638.4358-1-nm@ti.com
* arm64: dts: ti: k3-am642: Fix the L2 cache setsNishanth Menon2021-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | A53's L2 cache[1] on AM642[2] is 256KB. A53's L2 is fixed line length of 64 bytes and 16-way set-associative cache structure. 256KB of L2 / 64 (line length) = 4096 ways 4096 ways / 16 = 256 sets Fix the l2 cache-sets. [1] https://developer.arm.com/documentation/ddi0500/j/Level-2-Memory-System/About-the-L2-memory-system?lang=en [2] https://www.ti.com/lit/pdf/spruim2 Fixes: 8abae9389bdb ("arm64: dts: ti: Add support for AM642 SoC") Reported-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211113043635.4296-1-nm@ti.com
* arm64: dts: ti: j721e-main: Fix 'dtbs_check' in serdes_ln_ctrl nodeKishon Vijay Abraham I2021-12-031-1/+1
| | | | | | | | | | Fix 'dtbs_check' in serdes_ln_ctrl (mux@4080) node by changing the node name to mux-controller@4080. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211126084555.17797-3-kishon@ti.com
* arm64: dts: ti: j7200-main: Fix 'dtbs_check' serdes_ln_ctrl nodeKishon Vijay Abraham I2021-12-031-1/+1
| | | | | | | | | | Fix 'dtbs_check' in serdes_ln_ctrl (serdes-ln-ctrl@4080) node by changing the node name to mux-controller@4080. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211126084555.17797-2-kishon@ti.com
* arm64: dts: ti: k3-j721e: correct cache-sets infoPeng Fan2021-11-261-2/+2
| | | | | | | | | | | | | | | A72 Cluster has 48KB Icache, 32KB Dcache and 1MB L2 Cache - ICache is 3-way set-associative - Dcache is 2-way set-associative - Line size are 64bytes So correct the cache-sets info. Fixes: 2d87061e70dea ("arm64: dts: ti: Add Support for J721E SoC") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20211112063155.3485777-1-peng.fan@oss.nxp.com
* arm64: dts: ti: k3-j721e-sk: Add DDR carveout memory nodesSinthu Raja2021-10-051-0/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two carveout reserved memory nodes each have been added for each of the other remote processors devices within the MAIN domain on the TI J721E SK boards. These nodes are assigned to the respective rproc device nodes as well. The first region will be used as the DMA pool for the rproc devices, and the second region will furnish the static carveout regions for the firmware memory. An additional reserved memory node is also added to reserve a portion of the DDR memory to be used for performing inter-processor communication between all the remote processors running RTOS or baremetal firmwares. 8 MB of memory is reserved for this purpose, and this accounts for all the vrings and vring buffers between all the possible pairs of remote processors. The current carveout addresses and sizes are defined statically for each rproc device. The R5F processors do not have an MMU, and as such require the exact memory used by the firmwares to be set-aside. The C71x DSP processor does support a MMU called CMMU, but is not currently supported and as such requires the exact memory used by the firmware to be set-aside. The firmware images do not require any RSC_CARVEOUT entries in their resource tables to allocate the memory for firmware memory segments Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210929081333.26454-5-sinthu.raja@ti.com
* arm64: dts: ti: k3-j721e-sk: Add IPC sub-mailbox nodesSinthu Raja2021-10-051-0/+129
| | | | | | | | | | | | | | | | | | | | | | | Add the sub-mailbox nodes that are used to communicate between MPU and various remote processors present in the J721E SoCs to the J721E EAIK board. These include the R5F remote processors in the dual-R5F cluster (MCU_R5FSS0) in the MCU domain and the two dual-R5F clusters (MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; the two C66x DSP remote processors and the single C71x DSP remote processor in the MAIN domain. These sub-mailbox nodes utilize the System Mailbox clusters 0 through 4. All the remaining mailbox clusters are currently not used on A72 core, and are hence disabled. The sub-mailbox nodes added match the hard-coded mailbox configuration used within the TI RTOS IPC software packages. The R5F processor sub-systems are assumed to be running in Split mode, so a sub-mailbox node is used by each of the R5F cores. Only the sub-mailbox node for the first R5F core in each cluster is used in case of a Lockstep mode for that R5F cluster. Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210929081333.26454-4-sinthu.raja@ti.com
* arm64: dts: ti: Add support for J721E SKSinthu Raja2021-10-052-0/+730
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | J721E Starter Kit (SK)[1] is a low cost, small form factor board designed for TI’s J721E SoC. TI’s J721E SoC comprises of dual core A72, high performance vision accelerators, video codec accelerators, latest C71x and C66x DSP, high bandwidth real-time IPs for capture and display, GPU, dedicated safety island and security accelerators. The SoC is power optimized to provide best in class performance for industrial and automotive applications. J721E SK supports the following interfaces: * 4 GB LPDDR4 RAM * x1 Gigabit Ethernet interface * x1 USB 3.0 Type-C port * x3 USB 3.0 Type-A ports * x1 PCIe M.2 E Key * x1 PCIe M.2 M Key * 512 Mbit OSPI flash * x2 CSI2 Camera interface (RPi and TI Camera connector) * 40-pin Raspberry Pi GPIO header Add basic support for J721E-SK. [1] https://www.ti.com/tool/SK-TDA4VM Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210929081333.26454-3-sinthu.raja@ti.com
* arm64: dts: ti: iot2050: Add support for product generation 2 boardsJan Kiszka2021-10-054-0/+106
| | | | | | | | | | | | This adds the devices trees for IOT2050 Product Generation 2 (PG2) boards. We have Basic and an Advanced variants again, differing in number of cores, RAM size, availability of eMMC and further details. The major difference to PG1 is the used silicon revision (SR2.x on PG2). Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/cc868da8264324bde2c87d0c01d4763e3678c706.1632657917.git.jan.kiszka@web.de
* arm64: dts: ti: iot2050: Prepare for adding 2nd-generation boardsJan Kiszka2021-10-056-125/+178
| | | | | | | | | | | | | | The current IOT2050 devices are Product Generation 1 (PG1), using SR1.0 AM65x silicon. Upcoming PG2 devices will use SR2.x SoCs and will therefore need separate device trees. Prepare for that by factoring out common bits that will be shared across both generations. At this chance, drop a link to the product homepage to in the top-level dts files. Also fix a typo in my email address in some headers. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/31fece05f9728a852c0632985c4fa537cced4ece.1632657917.git.jan.kiszka@web.de
* arm64: dts: ti: iot2050: Add/enabled mailboxes and carve-outs for R5F coresJan Kiszka2021-10-051-2/+24
| | | | | | | | | | | | Analogously to the am654-base-board, configure the mailboxes for the two R5F cores, add them and the already existing memory carve-outs to the related MCU nodes. Allows to load applications under Linux onto the cores, e.g. the RTI watchdog firmware. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/1776f8be19b39a938d9248fcfc5332b753783c3e.1632657917.git.jan.kiszka@web.de
* arm64: dts: ti: iot2050: Disable SR2.0-only PRUsJan Kiszka2021-10-051-0/+24
| | | | | | | | | | | The IOT2050 devices described so far are using SR1.0 silicon, thus do not have the additional PRUs of the ICSSG of the SR2.0. Disable them. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Aswath Govindraju <a-govindraju@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/189a91866fb1af02e4fd2345dc56774aa069d5ba.1632657917.git.jan.kiszka@web.de
* arm64: dts: ti: iot2050: Flip mmc device ordering on Advanced devicesJan Kiszka2021-10-051-0/+2
| | | | | | | | | | | This ensures that the SD card will remain mmc0 across Basic and Advanced devices, also avoiding surprises for users coming from the downstream kernels. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/fe20d6346f119a28e47d129b616682001299cf0e.1632657917.git.jan.kiszka@web.de
* arm64: dts: ti: k3-j7200-common-proc-board: Add j7200-evm compatibleNishanth Menon2021-10-051-0/+3
| | | | | | | | | Add j7200-evm compatible to the board to allow the board to distinguish itself from other platforms that may be added in the future. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210925201430.11678-5-nm@ti.com
* arm64: dts: ti: k3-j721e-common-proc-board: Add j721e-evm compatibleNishanth Menon2021-10-051-0/+3
| | | | | | | | | Add j721e-evm compatible to the board to allow the board to distinguish itself from other platforms that are pending to be added. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210925201430.11678-4-nm@ti.com
* arm64: dts: ti: Makefile: Collate AM64 platforms togetherNishanth Menon2021-10-051-1/+0
| | | | | | | | | Make sure that the platforms are grouped together per SoC. This helps keep the Makefile readable as newer platforms get added to the list. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210915121442.27112-1-nm@ti.com
* arm64: dts: ti: k3-am64-main: Add ICSSG nodesSuman Anna2021-10-053-0/+296
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the DT nodes for the ICSSG0 and ICSSG1 processor subsystems that are present on the K3 AM64x SoCs. The two ICSSGs are identical to each other for the most part, with some of the peripheral pins from ICSSG1 not pinned out. Each ICSSG instance is represented by a PRUSS subsystem node and other child nodes. The nodes are all added and enabled in the common k3-am64-main.dtsi file by default. The MDIO nodes need pinctrl lines, and so should be enabled only on boards where they are actually wired and pinned out for ICSSG Ethernet. Any new board dts file should disable these if they are not sure. These are disabled in the existing AM64x board dts files to begin with. The ICSSGs on K3 AM64x SoCs are very similar to the versions of the ICSSG on K3 J721E and AM65x SR2.0 SoCs. The IRAM and BroadSize RAM sizes are all identical to those on J721E SoCs. All The ICSSG host interrupts intended towards the main Arm core are also shared with other processors on the SoC, and can be partitioned as per system integration needs. The ICSSG subsystem node contains the entire address space. The various sub-modules of the ICSSG are represented as individual child nodes (so platform devices themselves) of the PRUSS subsystem node. These include: - two Programmable Real-Time Units (PRUs) - two auxiliary PRU cores called RTUs - two Transmit Programmable Real-Time Units (Tx_PRUs) - Interrupt controller (INTC) - a 'memories' node containing all the ICSSG level Data RAMs - Real Time Media Independent Interface controller (MII_RT) - Gigabit capable MII_G_RT - ICSSG CFG sub-module providing two internal clock muxes, with the default clock parents also assigned using the assigned-clock-parents property. The default names for the firmware images for each PRU, RTU and Tx_PRU cores are defined as follows using the 'firmware-name' property (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 PRU0 Core : am64x-pru0_0-fw ; PRU1 Core : am64x-pru0_1-fw ICSSG0 RTU0 Core : am64x-rtu0_0-fw ; RTU1 Core : am64x-rtu0_1-fw ICSSG0 Tx_PRU0 Core : am64x-txpru0_0-fw ; Tx_PRU1 Core : am64x-txpru0_1-fw ICSSG1 PRU0 Core : am64x-pru1_0-fw ; PRU1 Core : am64x-pru1_1-fw ICSSG1 RTU0 Core : am64x-rtu1_0-fw ; RTU1 Core : am64x-rtu1_1-fw ICSSG1 Tx_PRU0 Core : am64x-txpru1_0-fw ; Tx_PRU1 Core : am64x-txpru1_1-fw Note: 1. The ICSSG INTC on AM64x SoCs share all the host interrupts with other processors, so use the 'ti,irqs-reserved' property in derivative board dts files _if_ any of them should not be handled by the host OS. 2. There are few more sub-modules like the Industrial Ethernet Peripherals (IEPs), eCAP, PWM, UART that do not have bindings and so will be added in the future. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210919202935.15604-1-s-anna@ti.com
* arm64: dts: ti: k3-am65: Relocate thermal-zones to SoC specific locationNishanth Menon2021-09-202-4/+4
| | | | | | | | | | | | | | | | When commit 64f9147d914d ("arm64: dts: ti: am654: Add thermal zones") introduced thermal-zones for am654, it defined as under the common am65-wakeup bus segment, when it is am654 specific (other SoC spins can have slightly different thermal characteristics). Futher, thermal-zones is introduced under simple-bus node, when it has no actual register or base address. So, move it to it's rightful place under am654 SoC dtsi under the base node. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Keerthy <j-keerthy@ti.com> Link: https://lore.kernel.org/r/20210916181801.32588-1-nm@ti.com
* arm64: dts: ti: ti-k3*: Introduce aliases for mmc nodesNishanth Menon2021-09-204-0/+9
| | | | | | | | | | | | | Since probe order of mmc can vary depending on device tree dependencies, Lets try and introduce a consistent definition of what mmc0, 1 are across platforms. NOTE: Certain platforms may choose to have overrides due to various legacy reasons, we permit that in the board specific alias definition. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20210915135415.5706-1-nm@ti.com
* arm64: dts: ti: k3-am65-main: Cleanup "ranges" property in "pcie" DT nodeKishon Vijay Abraham I2021-09-201-4/+4
| | | | | | | | | | | | | | | | *dtbs_check* on "Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml" YAML file resulted in the following errors. pcie@5500000: ranges: 'oneOf' conditional failed, one must be fixed: pcie@5600000: ranges: 'oneOf' conditional failed, one must be fixed Cleanup "ranges" property in "pcie" DT node to fix the above errors. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-7-kishon@ti.com
* arm64: dts: ti: j7200-main: Add *max-virtual-functions* for pcie-ep DT nodeKishon Vijay Abraham I2021-09-201-0/+1
| | | | | | | | | | J7200 has 4 virtual functions for the first four physical function. Add *max-virtual-functions* in pcie-ep DT node to represent the same. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-6-kishon@ti.com
* arm64: dts: ti: j7200-main: Fix "bus-range" upto 256 bus number for PCIeKishon Vijay Abraham I2021-09-201-1/+1
| | | | | | | | | | | | | commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") incorrectly added PCIe bus numbers from 0 to 15 (copy-paste from J721E node). Enable all the supported bus numbers from 0 to 255 defined in PCIe spec here. Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-5-kishon@ti.com
* arm64: dts: ti: j7200-main: Fix "vendor-id"/"device-id" properties of pcie nodeKishon Vijay Abraham I2021-09-201-2/+2
| | | | | | | | | | | | commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") incorrectly added "vendor-id" and "device-id" as 16-bit properties though both of them are 32-bit properties. Fix it here. Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-4-kishon@ti.com
* arm64: dts: ti: k3-j721e-main: Fix "bus-range" upto 256 bus number for PCIeKishon Vijay Abraham I2021-09-201-4/+4
| | | | | | | | | | | | | commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") restricted PCIe bus numbers from 0 to 15 (due to SMMU restriction in J721E). However since SMMU is not enabled, allow the full supported bus numbers from 0 to 255. Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-3-kishon@ti.com
* arm64: dts: ti: k3-j721e-main: Fix "max-virtual-functions" in PCIe EP nodesKishon Vijay Abraham I2021-09-201-4/+4
| | | | | | | | | | | | | commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") added "max-virtual-functions" to have 16 bit values. Fix "max-virtual-functions" in PCIe endpoint (EP) nodes to have 8 bit values instead of 16. Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-2-kishon@ti.com
* arm64: dts: ti: k3-am64-mcu: Add pinctrlChristian Gmeiner2021-09-141-0/+8
| | | | | | | | | Add the definition of the pinctrl for the MCU domain. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210818111747.88569-1-christian.gmeiner@gmail.com
* arm64: dts: ti: k3-am642-sk: Add pwm nodesLokesh Vutla2021-07-301-0/+64
| | | | | | | | | | | | | ecap0 can be configured to use pad ECAP0_IN_APWM_OUT (D18) which has a signal connected to Pin 1 of J3. Add support for adding this pinmux so that pwm can be observed on pin 1 of Header J3 Also mark all un-used epwm and ecap pwm nodes as disabled. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210721113625.17299-5-lokeshvutla@ti.com
* arm64: dts: ti: k3-am642-evm: Add pwm nodesLokesh Vutla2021-07-301-0/+56
| | | | | | | | | | | | | ecap0 can be configured to use pad ECAP0_IN_APWM_OUT (D18) which has a signal connected to Pin 1 of J12 on EVM. Add support for adding this pinmux so that pwm can be observed on pin 1 of Header J12 Also mark all un-used epwm and ecap pwm nodes as disabled. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210721113625.17299-4-lokeshvutla@ti.com
* arm64: dts: ti: k3-am64-main: Add ecap pwm nodesLokesh Vutla2021-07-301-0/+27
| | | | | | | | | | | There are 3 instances of ecap modules that are capable of generating a pwm when configured in apwm mode. Add DT nodes for these 3 ecap instances. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210721113625.17299-3-lokeshvutla@ti.com
* arm64: dts: ti: k3-am64-main: Add epwm nodesLokesh Vutla2021-07-301-0/+87
| | | | | | | | | Add DT nodes for all epwm instances present in AM64 SoC. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210721113625.17299-2-lokeshvutla@ti.com
* arm64: dts: ti: k3-am642-evm/sk: Add DDR carveout memory nodes for R5FsSuman Anna2021-06-182-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two carveout reserved memory nodes each have been added for each of the R5F remote processor devices within the MAIN domain on the TI AM642 EVM and SK boards. These nodes are assigned to the respective rproc device nodes as well. The first region will be used as the DMA pool for the rproc devices, and the second region will furnish the static carveout regions for the firmware memory. An additional reserved memory node is also added to reserve a portion of the DDR memory to be used for performing inter-processor communication between all the remote processors running RTOS or baremetal firmwares. 8 MB of memory is reserved for this purpose, and this accounts for all the vrings and vring buffers between all the possible pairs of remote processors. The current carveout addresses and sizes are defined statically for each rproc device. The R5F processors do not have an MMU, and as such require the exact memory used by the firmwares to be set-aside. The firmware images do not require any RSC_CARVEOUT entries in their resource tables to allocate the memory for firmware memory segments. NOTE: 1. The R5F1 carveouts are needed only if the R5F cluster is running in Split (non Single-CPU) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. 2. The AM64x SoCs do not have any DSPs and one less R5F cluster compared to J721E SoCs. So, while the carveout memories reserved for the R5F clusters present on the SoC match to those on J721E, the overall memory map reserved for firmwares is quite different. The number of R5F clusters on AM64x SoCs are same as on J7200 SoCs, but the AM64x SoCs also have an additional M4F core, so the RTOS IPC memory region is 1 MB higher than on J7200 SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Praneeth Bajjuri <praneeth@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210615195718.15898-4-s-anna@ti.com
* arm64: dts: ti: k3-am642-evm/sk: Add mailboxes to R5FsSuman Anna2021-06-182-0/+32
| | | | | | | | | | | | | | | | | | | Add the required 'mboxes' property to all the R5F processors for the TI AM642 EVM and SK boards. The mailboxes and some shared memory are required for running the Remote Processor Messaging (RPMsg) stack between the host processor and each of the R5Fs. The chosen sub-mailboxes match the values used in the current firmware images. This can be changed, if needed, as per the system integration needs after making appropriate changes on the firmware side as well. Note that any R5F Core1 resources are needed and used only when that R5F cluster is configured for Split-mode. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Praneeth Bajjuri <praneeth@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210615195718.15898-3-s-anna@ti.com
* arm64: dts: ti: k3-am64-main: Add MAIN domain R5F cluster nodesSuman Anna2021-06-181-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The AM64x SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS) subsystems/clusters. Both the R5F clusters are present within the MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be configured at boot time to be either run in a new "Single-CPU" mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. The mode is restricted to "Single-CPU" on some devices with the appropriate eFuse bit set, but the most common devices support both modes. These subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - ATCM and BTCM (further interleaved into two banks). The TCMs of both Cores are combined in Single-CPU mode to provide a larger 128 KB of memory. The other notable difference is that the TCMs are spaced 1 MB apart on these SoCs unlike the existing SoCs. Add the DT nodes for both these MAIN domain R5F cluster/subsystems, the two R5F cores are added as child nodes to each of the corresponding R5F cluster node. Both the clusters are configured to run in Split mode by default, with the ATCMs enabled to allow the R5 cores to execute code from DDR with boot-strapping code from ATCM. The inter-processor communication between the main A72 cores and these processors is achieved through shared memory and Mailboxes. The following firmware names are used by default for these cores, and can be overridden in a board dts file if desired: MAIN R5FSS0 Core0: am64-main-r5f0_0-fw (both in Single-CPU & Split modes) MAIN R5FSS0 Core1: am64-main-r5f0_1-fw (needed only in Split mode) MAIN R5FSS1 Core0: am64-main-r5f1_0-fw (both in Single-CPU & Split modes) MAIN R5FSS1 Core1: am64-main-r5f1_1-fw (needed only in Split mode) NOTE: A R5FSS cluster can be configured in "Single-CPU" mode by using a value of 2 for the "ti,cluster-mode" property. Value of 1 is not permitted (fails the dtbs_check). Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Praneeth Bajjuri <praneeth@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210615195718.15898-2-s-anna@ti.com
* arm64: dts: ti: k3-am64-main: Update TF-A load address to workaround USB DFU ↵Aswath Govindraju2021-06-161-2/+2
| | | | | | | | | | | | | | | limitation Due to a limitation for USB DFU boot mode, SPL load address has to be less than or equal to 0x70001000. So, load address of SPL and TF-A have been moved to 0x70000000 and 0x701c0000 respectively, in U-Boot version 2021.10. Therefore, update TF-A's location in the device tree node. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210616171224.24635-4-a-govindraju@ti.com
* arm64: dts: ti: k3-am64-main: Reserve OCMRAM for DMSC-lite and secure proxy ↵Aswath Govindraju2021-06-161-0/+8
| | | | | | | | | | | | | | | | | | | | communication The final 128KB in SRAM is reserved by default for DMSC-lite code and secure proxy communication buffer. The memory region used for DMSC-lite code can be optionally freed up by secure firmware API[1]. However, the buffer for secure proxy communication is not configurable. This default hardware configuration is unique for AM64. Therefore, indicate the area reserved for DMSC-lite code and secure proxy communication buffer in the oc_sram device tree node. [1] - http://downloads.ti.com/tisci/esd/latest/6_topic_user_guides/security_handover.html#triggering-security-handover Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210616171224.24635-3-a-govindraju@ti.com
generated by cgit (git 2.34.1) at 2025-02-24 11:58:43 +0000