- 01 Apr, 2021 3 commits
-
-
Pratyush Yadav authored
The TI specific compatible should be followed by the generic "cdns,qspi-nor" compatible. Signed-off-by:
Pratyush Yadav <p.yadav@ti.com> Reviewed-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210326130034.15231-4-p.yadav@ti.com
-
Pratyush Yadav authored
The TI specific compatible should be followed by the generic "cdns,qspi-nor" compatible. Signed-off-by:
-
Pratyush Yadav authored
The TI specific compatible should be followed by the generic "cdns,qspi-nor" compatible. Signed-off-by:
-
- 26 Mar, 2021 3 commits
-
-
Aswath Govindraju authored
arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems The following speed modes are now supported in J7200 SoC, - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1]. - UHS-I speed modes in MMCSD1 subsystem [1]. Add support for UHS-I modes by adding voltage regulator device tree nodes and corresponding pinmux details, to power cycle and voltage switch cards. Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1 device tree nodes. Also update the delay values for various speed modes supported, based on the revised january 2021 J7200 datasheet[2]. [1] - section 12.3.6.1.1 MMCSD Features, in https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf, (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021) [2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf, (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021) Signed-off-by:Aswath Govindraju <a-govindraju@ti.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20210326064120.31919-4-a-govindraju@ti.com
-
Faiz Abbas authored
There are 6 gpio instances inside SoC with 2 groups as show below: Group one: wkup_gpio0, wkup_gpio1 Group two: main_gpio0, main_gpio2, main_gpio4, main_gpio6 Only one instance from each group can be used at a time. So use main_gpio0 and wkup_gpio0 in current linux context and disable the rest of the nodes. Signed-off-by:Faiz Abbas <faiz_abbas@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210326064120.31919-3-a-govindraju@ti.com
-
Faiz Abbas authored
There are 4 instances of gpio modules in main domain: gpio0, gpio2, gpio4 and gpio6 Groups are created to provide protection between different processor virtual worlds. Each of these modules I/O pins are muxed within the group. Exactly one module can be selected to control the corresponding pin by selecting it in the pad mux configuration registers. This group in main domain pins out 69 lines (5 banks). Add DT modes for each module instance in the main domain. Similar to the gpio groups in main domain, there is one gpio group in wakeup domain with 2 module instances in it. The gpio group pins out 72 pins (6 banks) of the first 85 gpio lines. Add DT nodes for each module instance in the wakeup domain. Signed-off-by:
-
- 25 Mar, 2021 3 commits
-
-
Suman Anna authored
Add the sub-mailbox nodes that are used to communicate between MPU and various remote processors present in the AM64x SoCs for the AM642 EVM and AM642 SK boards. These include the R5F remote processors in the two dual-R5F clusters (MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; and a M4 processor in the MCU safety island. These sub-mailbox nodes utilize the System Mailbox clusters 2, 4 and 6. The remaining clusters 3, 5 and 7 are currently not used, and so are disabled. Clusters 0 and 1 were never added to the dts file as they do not support interrupts towards the A53 core. 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 Single-CPU mode for that R5F cluster. NOTE: The cluster nodes only have the Mailbox IP interrupt outputs that are routed to the GIC_SPI. The sub-mailbox nodes' irq-id are indexing into the listed interrupts, with the usr-id using the actual interrupt output line number from the Mailbox IP. Signed-off-by:
Suman Anna <s-anna@ti.com> Signed-off-by:
Gowtham Tammana <g-tammana@ti.com> Link: https://lore.kernel.org/r/20210322185430.957-4-s-anna@ti.com
-
Suman Anna authored
The AM64 MAIN domain contains a Mailbox IP instance with multiple clusters, and is a variant of the IP on current AM65x and J721E SoCs. The AM64x SoC has only 8 clusters with no interrupts routed to the A53 core on the first 2 clusters. The interrupt outputs from the IP do not go through any Interrupt Routers and are hard-wired to each processor, with only couple of interrupts from each cluster reaching the A53 core. Add all the Mailbox clusters that generate interrupts towards the A53 core as their own nodes under the cbass_main node instead of creating an almost empty parent node for the Mailbox IP and the clusters as its child nodes. All these nodes are enabled by default in the base dtsi file, but any cluster that does not define any child sub-mailbox nodes should be disabled in the corresponding board dts files. Signed-off-by:
-
Suman Anna authored
The AM64x SoC contains a HwSpinlock IP instance that is a minor variant of the IP on existing TI K3 SoCs such as AM65x, J721E or J7200 SoCs. Add the DT node for this on AM64x SoCs. The node is present within the MAIN domain, and is added as a child node under the cbass_main node. Signed-off-by:
-
- 22 Mar, 2021 2 commits
-
-
Aswath Govindraju authored
The gpio0 subsystem present in MCU domain might be used by firmware and is not pinned out in evm/sk. Therefore, reserve it for MCU firmware. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210319051950.17549-3-a-govindraju@ti.com
-
Aswath Govindraju authored
Add device tree nodes for GPIO modules and interrupt controller in main and mcu domains. Signed-off-by:
-
- 18 Mar, 2021 3 commits
-
-
Vignesh Raghavendra authored
Both AM64 EVM and SK have a 512Mb S28HS512T Octal SPI NOR flash. Add DT node for the same. Signed-off-by:
-
Vignesh Raghavendra authored
AM64 SoC has a single Octal SPI (OSPI) instance under Flash SubSystem (FSS). Add DT entry for the same. Signed-off-by:
-
Vignesh Raghavendra authored
AM64 SoC has a single ADC IP with 8 channels. Add DT node for the same. Default usecase is to control ADC from non Linux core on the system on AM642 GP EVM, therefore mark the node as reserved in k3-am642-evm.dts file. ADC lines are not pinned out on AM642 SK board, therefore disable the node in k3-am642-sk.dts file. Signed-off-by:
-
- 17 Mar, 2021 2 commits
-
-
Aswath Govindraju authored
AM64 EVM board has a micro USB 2.0 AB connector and the USB0_VBUS is connected with a resistor divider in between. USB0_DRVVBUS pin is muxed between USB0_DRVVBUS and GPIO1_79 signals. Add the corresponding properties and set the pinmux mode for USB subsystem in the evm dts file. Signed-off-by:
Roger Quadros <rogerq@ti.com> Link: https://lore.kernel.org/r/20210317043007.18272-3-a-govindraju@ti.com
-
Aswath Govindraju authored
Add DT node for the single USB subsystem in main dtsi file. Signed-off-by:
-
- 11 Mar, 2021 9 commits
-
-
Jan Kiszka authored
Add support for two Siemens SIMATIC IOT2050 variants, Basic and Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus differ in their number of cores and availability of security features. Furthermore the Advanced version comes with more RAM, an eMMC and a few internal differences. Based on original version by Le Jin. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
-
Jan Kiszka authored
These boards are based on AM6528 GP and AM6548 HS SOCs. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/173ce7d928ed9f352af7673dd44c6c76a1466eb5.1615473223.git.jan.kiszka@siemens.com
-
Jan Kiszka authored
Add prefix for Siemens AG. Signed-off-by:
-
Aswath Govindraju authored
Add pinmux details and device tree node for the EEPROM attached to SPI0 module in main domain. Signed-off-by:
-
Pratyush Yadav authored
TI J7200 has the Cadence OSPI controller for interfacing with OSPI flashes. Add its node to allow using SPI flashes. Signed-off-by:
-
Pratyush Yadav authored
Set the Tx bus width to 8 so 8D-8D-8D mode can be selected. Change the frequency to 25 MHz. This is the frequency that the flash has been successfully tested with in Octal DTR mode. The total performance should still increase since 8D-8D-8D mode should be at least twice as fast as 1S-1S-8S mode. Signed-off-by:
-
Pratyush Yadav authored
Set the Tx bus width to 8 so 8D-8D-8D mode can be selected. Change the frequency to 25 MHz. This is the frequency that the flash has been successfully tested with in Octal DTR mode. The total performance should still increase since 8D-8D-8D mode should be at least twice as fast as 1S-1S-8S mode. Signed-off-by:
-
Aswath Govindraju authored
arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems According to latest errata of J721e [1], HS400 mode is not supported in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2 subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode. Also, update the itap delay values for all the MMCSD subsystems according the latest J721e data sheet[2] [1] - https://www.ti.com/lit/er/sprz455/sprz455.pdf [2] - https://www.ti.com/lit/ds/symlink/tda4vm.pdf Fixes: cd48ce86 ("arm64: dts: ti: k3-j721e-common-proc-board: Add support for SD card UHS modes") Signed-off-by:
-
Jan Kiszka authored
Add the DT entry for a watchdog based on RTI1. On SR1.0 silicon, it requires additional firmware on the MCU R5F cores to handle the expiry, e.g. https://github.com/siemens/k3-rti-wdt. As this firmware will also lock the power domain to protect it against premature shutdown, mark it shared. Signed-off-by:
Praneeth Bajjuri <praneeth@ti.com> Link: https://lore.kernel.org/r/279c20fa-6e5e-4f88-9cd1-f76297a28a19@web.de
-
- 09 Mar, 2021 14 commits
-
-
Suman Anna authored
Add the DT nodes for the ICSSG0 and ICSSG1 processor subsystems that are present on the K3 J721E SoCs. The two ICSSGs are identical to each other for the most part, with the ICSSG1 supporting slightly enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance is represented by a PRUSS subsystem node and other child nodes. These nodes are enabled by default. The ICSSGs on K3 J721E SoCs are revised versions of the ICSSG on the first AM65x SR1.0 SoCs. The PRU IRAMs are slightly smaller, and the IP includes two new auxiliary PRU cores called Tx_PRUs. The Tx_PRUs have 6 KB of IRAMs and leverage the same host interrupts as the regular PRU cores. 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 the two PRU cores, two RTU cores, two Tx_PRU cores and the interrupt controller. All the Data RAMs are represented within a child node of its own named 'memories' without any compatible. The Real Time Media Independent Interface controller (MII_RT), the Gigabit capable MII_G_RT and the CFG sub-module are represented as syscon nodes. The ICSSG CFG sub-module provides two internal clock muxes, and these are represented as children of the CFG child node 'clocks' by the 'coreclk-mux' and iepclk-mux' clk nodes. The default parents for these mux clocks are also defined using the assigned-clock-parents property. The DT nodes use all standard properties. The regs property in the PRU/RTU/Tx_PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU/RTU/Tx_PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU, RTU and Tx_PRU cores are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 PRU0 Core : j7-pru0_0-fw ; PRU1 Core : j7-pru0_1-fw ICSSG0 RTU0 Core : j7-rtu0_0-fw ; RTU1 Core : j7-rtu0_1-fw ICSSG0 Tx_PRU0 Core : j7-txpru0_0-fw ; Tx_PRU1 Core : j7-txpru0_1-fw ICSSG1 PRU0 Core : j7-pru1_0-fw ; PRU1 Core : j7-pru1_1-fw ICSSG1 RTU0 Core : j7-rtu1_0-fw ; RTU1 Core : j7-rtu1_1-fw ICSSG1 Tx_PRU0 Core : j7-txpru1_0-fw ; Tx_PRU1 Core : j7-txpru1_1-fw Note: 1. The ICSSG INTC on J721E 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), MDIO, PWM, UART that do not have bindings and so will be added in the future. Signed-off-by:
-
Suman Anna authored
Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems that are present on the K3 AM65x SoCs. The three ICSSGs are identical to each other for the most part, with the ICSSG2 supporting slightly enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance is represented by a PRUSS subsystem node. These nodes are enabled by default. The ICSSGs on K3 AM65x SoCs are super-sets of the PRUSS on the AM57xx/ 6AK2G SoCs except for larger Shared Data RAM and the lack of a PRU-ICSS crossbar. They include two auxiliary PRU cores called RTUs and few other additional sub-modules. The interrupt integration is also different on the K3 AM65x SoCs and are propagated through various SoC-level Interrupt Router and Interrupt Aggregator blocks. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP used on J721E SoCs, and has two new auxiliary PRU cores called Tx_PRUs. The Tx_PRUs have 6 KB of IRAMs and leverage the same host interrupts as the regular PRU cores. The Broadside (BS) RAM within each core is also sized differently w.r.t SR1.0. 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 the various PRU cores and the interrupt controller. All the Data RAMs are represented within a child node of its own named 'memories' without any compatible. The Real Time Media Independent Interface controllers (MII_RT and MII_G_RT), and the CFG sub-module are represented as syscon nodes. The ICSSG CFG module has clock muxes for IEP clock and CORE clock, these clk nodes are added under the CFG child node 'clocks'. The default parents for these mux clocks are also assigned. The DT nodes use all standard properties. The regs property in the PRU/RTU/Tx_PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU/RTU/Tx_PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU, RTU and Tx_PRU cores are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 PRU0 Core : am65x-pru0_0-fw ; PRU1 Core : am65x-pru0_1-fw ICSSG0 RTU0 Core : am65x-rtu0_0-fw ; RTU1 Core : am65x-rtu0_1-fw ICSSG0 Tx_PRU0 Core : am65x-txpru0_0-fw ; Tx_PRU1 Core : am65x-txpru0_1-fw ICSSG1 PRU0 Core : am65x-pru1_0-fw ; PRU1 Core : am65x-pru1_1-fw ICSSG1 RTU0 Core : am65x-rtu1_0-fw ; RTU1 Core : am65x-rtu1_1-fw ICSSG1 Tx_PRU0 Core : am65x-txpru1_0-fw ; Tx_PRU1 Core : am65x-txpru1_1-fw ICSSG2 PRU0 Core : am65x-pru2_0-fw ; PRU1 Core : am65x-pru2_1-fw ICSSG2 RTU0 Core : am65x-rtu2_0-fw ; RTU1 Core : am65x-rtu2_1-fw ICSSG2 Tx_PRU0 Core : am65x-txpru2_0-fw ; Tx_PRU1 Core : am65x-txpru2_1-fw Note: 1. The ICSSG nodes are all added as per the SR2.0 device. Any sub-module IP differences need to be handled within the driver using SoC device match logic or separate dts/overlay files (if needs to be supported) with the Tx_PRU nodes expected to be disabled at the minimum. 2. The ICSSG INTC on AM65x SoCs share 5, 6, 7 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. 3. There are few more sub-modules like the Industrial Ethernet Peripherals (IEPs), MDIO, PWM, UART that do not have bindings and so will be added in the future. Signed-off-by:
-
Vignesh Raghavendra authored
AM642 SK board has 2 CPSW3g ports connected through TI DP83867 PHYs. Add DT entries for the same. Signed-off-by:
-
Vignesh Raghavendra authored
On am642-evm the CPSW3g ext. Port1 is directly connected to TI DP83867 PHY and Port2 is connected to TI DP83869 PHY which is shared with ICSS subsystem. The TI DP83869 PHY MII interface is configured using pinmux for CPSW3g, while MDIO bus is connected through GPIO controllable 2:1 TMUX154E switch (MDIO GPIO MUX) which has to be configured to route MDIO bus from CPSW3g to TI DP83869 PHY. Hence add networking support for am642-evm: - add CPSW3g MDIO and RGMII pinmux entries for both ext. ports; - add CPSW3g nodes; - add mdio-mux-multiplexer DT nodes to represent above topology. Signed-off-by:
-
Grygorii Strashko authored
Add DT node for the Main domain CPTS. Signed-off-by:
-
Vignesh Raghavendra authored
Add CPSW3g DT node with two external ports, MDIO and CPTS support. For CPSW3g DMA channels the ASEL is set to 15 (AM642x per DMA channel coherency feature), so that CPSW DMA channel participates in Coherency and thus avoid need to cache maintenance for SKBs. This improves bidirectional TCP performance by up to 100Mbps (on 1G link). Signed-off-by:
-
Jan Kiszka authored
This is demanded by the parent binding of ti,am654-pcie-rc, see Documentation/devicetree/bindings/pci/designware-pcie.txt. Signed-off-by:
-
Lokesh Vutla authored
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. It supports the following interfaces: * 2 GB LPDDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode * x1 USB 3.0 Type-A port * x1 UHS-1 capable µSD card slot * 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837 * 512 Mbit OSPI flash * x2 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin Raspberry Pi compatible GPIO header * 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO) * 54-pin header for Programmable Realtime Unit (PRU) IO pins * Interface for remote automation. Includes: * power measurement and reset control * boot mode change Add basic support for AM642 SK. Signed-off-by:
-
Lokesh Vutla authored
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. Add DT binding documentation for AM642 SK. Signed-off-by:
-
Dave Gerlach authored
The AM642 EValuation Module (EVM) is a board that provides access to various peripherals available on the AM642 SoC, such as PCIe, USB 2.0, CPSW Ethernet, ADC, and more. Introduce support for the AM642 EVM to enable mmc boot, including enabling UART and I2C on the board. Signed-off-by:
Dave Gerlach <d-gerlach@ti.com> Tested-by:
-
Peter Ujfalusi authored
Add the nodes for DMSS INTA, BCDMA and PKTDMA to enable the use of the DMAs in the system. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Dave Gerlach authored
The AM642 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable applications such as Motor Drives, PLC, Remote IO and IoT Gateways. Some highlights of this SoC are: * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F MCUs, and a single Cortex-M4F. * Two Gigabit Industrial Communication Subsystems (ICSSG). * Integrated Ethernet switch supporting up to a total of two external ports. * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other peripherals. * Centralized System Controller for Security, Power, and Resource Management (DMSC). See AM64X Technical Reference Manual (SPRUIM2, Nov 2020) for further details: https://www.ti.com/lit/pdf/spruim2 Introduce basic support for the AM642 SoC to enable ramdisk or MMC boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals under cbass_main and the i2c, spi, and uart MCU domain periperhals under cbass_mcu. Signed-off-by:
-
Dave Gerlach authored
Add pinctrl macros for AM64 SoC. These macro definitions are similar to that of previous platforms, but adding new definitions to avoid any naming confusions in the soc dts files. Unlike what checkpatch insists, we do not need parentheses enclosing the values for this macro as we do intend it to generate two separate values as has been done for other similar platforms. Signed-off-by:
-
Dave Gerlach authored
The AM642 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable applications such as Motor Drives, PLC, Remote IO and IoT Gateways. Some highlights of this SoC are: * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F MCUs, and a single Cortex-M4F. * Two Gigabit Industrial Communication Subsystems (ICSSG). * Integrated Ethernet switch supporting up to a total of two external ports. * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other peripherals. * Centralized System Controller for Security, Power, and Resource Management (DMSC). See AM64X Technical Reference Manual (SPRUIM2, Nov 2020) for further details: https://www.ti.com/lit/pdf/spruim2Signed-off-by:
-
- 06 Mar, 2021 1 commit
-
-
Linus Torvalds authored
-
