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 <p.yadav@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210305153926.3479-3-p.yadav@ti.com
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 <p.yadav@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210305153926.3479-2-p.yadav@ti.com
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: cd48ce86a4 ("arm64: dts: ti: k3-j721e-common-proc-board: Add support for SD card UHS modes")
Signed-off-by: Aswath Govindraju <a-govindraju@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/20210305054104.10153-1-a-govindraju@ti.com
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: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Praneeth Bajjuri <praneeth@ti.com>
Link: https://lore.kernel.org/r/279c20fa-6e5e-4f88-9cd1-f76297a28a19@web.de
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 <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210304160712.8452-3-s-anna@ti.com
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210304160712.8452-2-s-anna@ti.com
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: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210304211038.12511-4-grygorii.strashko@ti.com
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: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210304211038.12511-2-grygorii.strashko@ti.com
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 <lokeshvutla@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20210226184251.26451-3-lokeshvutla@ti.com
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: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Tested-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20210226144257.5470-6-d-gerlach@ti.com
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 <d-gerlach@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210226144257.5470-5-d-gerlach@ti.com
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20210226144257.5470-4-d-gerlach@ti.com
We can use CPU specific pmu configuration to expose the appropriate
CPU specific events rather than just the basic generic pmuv3 perf
events.
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Tero Kristo <kristo@kernel.org>
Link: https://lore.kernel.org/r/20210120195145.32259-1-nm@ti.com
Now the dtbs_check produces below warnings
sdhci@4f80000: clock-names:0: 'clk_ahb' was expected
sdhci@4f80000: clock-names:1: 'clk_xin' was expected
$nodename:0: 'sdhci@4f80000' does not match '^mmc(@.*)?$'
Fix above warnings by updating mmc DT definitions to follow
sdhci-am654.yaml bindings:
- rename sdhci dt nodes to 'mmc@'
- swap clk_xin/clk_ahb clocks, the clk_ahb clock expected to be defined
first
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20210115193016.5581-1-grygorii.strashko@ti.com
Two carveout reserved memory nodes each have been added for each of the
R5F remote processor devices within both the MCU and MAIN domains on the
TI J7200 EVM 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 device, 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. 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
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 either
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-LockStep) 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 J7200 SoCs have no 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.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210111184554.6748-4-s-anna@ti.com
Add the required 'mboxes' property to all the R5F processors for the
TI J7200 common processor board. 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 nodes are therefore
added in the common k3-j7200-som-p0.dtsi file so that all of these can
be co-located.
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>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210111184554.6748-3-s-anna@ti.com
The J7200 SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster is present within the MCU
domain (MCU_R5FSS0), and the other one is present within the MAIN
domain (MAIN_R5FSS0). Each of these can be configured at boot time
to be either run in a LockStep mode or in an Asymmetric Multi
Processing (AMP) fashion in Split-mode. 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 LockStep-mode
to provide a larger 128 KB of memory, but otherwise are functionally
similar to those on J721E SoCs.
Add the DT nodes for both the MCU and MAIN domain R5F cluster/subsystems,
the two R5F cores are added as child nodes to each of the R5F cluster
nodes. The clusters are configured to run in LockStep 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:
MCU R5FSS0 Core0: j7200-mcu-r5f0_0-fw (both in LockStep and Split modes)
MCU R5FSS0 Core1: j7200-mcu-r5f0_1-fw (needed only in Split mode)
MAIN R5FSS0 Core0: j7200-main-r5f0_0-fw (both in LockStep & Split modes)
MAIN R5FSS0 Core1: j7200-main-r5f0_1-fw (needed only in Split mode)
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210111184554.6748-2-s-anna@ti.com
x2 lane PCIe slot in the common processor board is enabled and connected to
j7200 SOM. Add PCIe DT node in common processor board to reflect the
same.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210105151421.23237-7-kishon@ti.com
Add sub-nodes to SERDES0 DT node to represent SERDES0 is connected
to PCIe and QSGMII (multi-link SERDES).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210105151421.23237-6-kishon@ti.com
Add PCIe device tree node (both RC and EP) for the single PCIe
instance present in j7200.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210105151421.23237-5-kishon@ti.com
Add dt node for the single instance of WIZ (SERDES wrapper) and
SERDES module shared by PCIe, CPSW (SGMII/QSGMII) and USB.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210105151421.23237-4-kishon@ti.com
Cadence IP in J721E supports a maximum of 32 outbound regions. However
commit 4e5833884f ("arm64: dts: ti: k3-j721e-main: Add PCIe device
tree nodes") incorrectly added this as 16 outbound regions. Now that
"cdns,max-outbound-regions" is an optional property with default value
as 32, remove "cdns,max-outbound-regions" from endpoint DT node.
(Since this doesn't impact existing functionality, it need not be
backported to older kernels).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210105151421.23237-2-kishon@ti.com
Add support for UHS modes for the SD card connected at sdhci1. This
involves adding regulators for voltage switching and power cycling the
SD card and removing the no-1-8-v property.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20201129175223.21751-3-nsekhar@ti.com
There are couple of places where INTA interrupt controller
lacks #interrupt-cells property. This leads to warnings of
the type:
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi:147.51-156.5: Warning (interrupt_provider): /bus@100000/main-navss/interrupt-controller@33d00000: Missing #interrupt-cells in interrupt provider
when building TI device-tree files with W=2 warning level.
Fix these.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20201127210128.9151-1-nsekhar@ti.com
J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3
The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
usable with the J7200 SOM.
Correct the expander name from exp4 to exp3 and at the same time add the
line names as well.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20201120073533.24486-3-peter.ujfalusi@ti.com
The J7200 SOM have additional io expander which is used to control several
SOM level muxes to make sure that the correct signals are routed to the
correct pin on the SOM <-> CPB connectors.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20201120073533.24486-2-peter.ujfalusi@ti.com
Add the sub-mailbox nodes that are used to communicate between MPU and
various remote processors present in the J7200 SoCs to the J7200 common
processor board. These include the R5F remote processors in the dual-R5F
clusters in the MCU domain (MCU_R5FSS0) and the MAIN domain (MAIN_R5FSS0).
These sub-mailbox nodes utilize the System Mailbox clusters 0 and 1. All
the remaining mailbox clusters are currently not used on A72 core, and
so are disabled. The nodes are added in the k3-j7200-som-p0.dtsi file
to co-locate these alongside future reserved-memory nodes required for
remoteprocs.
The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. A sub-mailbox node is added
for each of the R5F cores to accommodate the R5F processor sub-systems
running in Split mode. Only the sub-mailbox node for the first R5F core in
each cluster is used in case of Lockstep mode for that R5F cluster.
NOTE:
The GIC_SPI interrupts to be used are dynamically allocated and managed
by the System Firmware through the ti-sci-intr irqchip driver. So, only
valid interrupts that are used by the sub-mailbox devices (each cluster's
User 0 IRQ output) are enabled. This is done to minimize the number of
NavSS Interrupt Router outputs utilized.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Praneeth Bajjuri <praneeth@ti.com>
Link: https://lore.kernel.org/r/20201026232637.15681-4-s-anna@ti.com
The J7200 Main NavSS block contains a Mailbox IP instance with
multiple clusters, and follows the same integration style as on
J721E SoCs.
Add all the Mailbox clusters as their own nodes under the MAIN
NavSS interconnect node instead of creating an almost empty parent
node for the new K3 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.
NOTE:
The NavSS only has a limited number of interrupts, so none of the
interrupts generated by a Mailbox IP are added by default. Only
the needed interrupts that are targeted towards the A72 GIC will
have to be added later on in the board dts files alongside the
corresponding sub-mailbox child nodes.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Praneeth Bajjuri <praneeth@ti.com>
Link: https://lore.kernel.org/r/20201026232637.15681-3-s-anna@ti.com
The Main NavSS block on J7200 SoCs contains a HwSpinlock IP instance that
is same as the IP on AM65x and J721E SoCs. Add the DT node for this on
J7200 SoCs. The node is present within the Main NavSS block, and is added
as a child node under the main_navss interconnect node.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Praneeth Bajjuri <praneeth@ti.com>
Link: https://lore.kernel.org/r/20201026232637.15681-2-s-anna@ti.com
Follow the device tree standards that states to set the
status="reserved" if an device is operational, but used by a non-linux
firmware in the system.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20201113211826.13087-6-nm@ti.com
The default state of a device tree node is "okay". There is no specific
use of explicitly adding status = "okay" in the board dts.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Link: https://lore.kernel.org/r/20201113211826.13087-5-nm@ti.com
The default state of a device tree node is "okay". There is no specific
use of explicitly adding status = "okay" in the SoC dtsi.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Link: https://lore.kernel.org/r/20201113211826.13087-4-nm@ti.com
The device tree standard states that when the status property is
not present under a node, the okay value is assumed. There are many
reasons for doing the same, the number of strings in the device
tree, default power management functionality, etc. are a few of the
reasons.
In general, after a few rounds of discussions [1] there are few
options one could take when dealing with SoC dtsi and board dts
a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
to prevent messy board files, when more boards are added per SoC, we
optimize and disable commonly un-used nodes in board-common.dtsi
b. SoC dtsi disables all hardware dependent nodes by default and board
dts files enable nodes based on a need basis.
c. Subjectively pick and choose which nodes we will disable by default
in SoC dtsi and over the years we can optimize things and change
default state depending on the need.
While there are pros and cons on each of these approaches, the right
thing to do will be to stick with device tree default standards and
work within those established rules. So, we choose to go with option
(a).
Lets cleanup defaults of j721e SoC dtsi before this gets more harder
to cleanup later on and new SoCs are added.
The only functional difference between the dtb generated is
status='okay' is no longer necessary for mcasp10 and depends on the
default state.
NOTE: There is a known risk of omission that new board dts developers
might miss reviewing both the board schematics in addition to all the
DT nodes of the SoC when setting appropriate nodes status to disable
or reserved in the board dts. This can expose issues in drivers that
may not anticipate an incomplete node (example: missing appropriate
board properties) being in an "okay" state. These cases are considered
bugs and need to be fixed in the drivers as and when identified.
[1] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20201113211826.13087-3-nm@ti.com
The device tree standard states that when the status property is
not present under a node, the okay value is assumed. There are many
reasons for doing the same, the number of strings in the device
tree, default power management functionality, etc. are a few of the
reasons.
In general, after a few rounds of discussions [1] there are few
options one could take when dealing with SoC dtsi and board dts
a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
to prevent messy board files, when more boards are added per SoC, we
optimize and disable commonly un-used nodes in board-common.dtsi
b. SoC dtsi disables all hardware dependent nodes by default and board
dts files enable nodes based on a need basis.
c. Subjectively pick and choose which nodes we will disable by default
in SoC dtsi and over the years we can optimize things and change
default state depending on the need.
While there are pros and cons on each of these approaches, the right
thing to do will be to stick with device tree default standards and
work within those established rules. So, we choose to go with option
(a).
Lets cleanup defaults of am654 SoC dtsi before this gets more harder
to cleanup later on and new SoCs are added.
The dtb generated is identical with the patch and it is just cleanup to
ensure we have a clean usage model
NOTE: There is a known risk of omission that new board dts developers
might miss reviewing both the board schematics in addition to all the
DT nodes of the SoC when setting appropriate nodes status to disable
or reserved in the board dts. This can expose issues in drivers that
may not anticipate an incomplete node (example: missing appropriate
board properties) being in an "okay" state. These cases are considered
bugs and need to be fixed in the drivers as and when identified.
[1] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20201113211826.13087-2-nm@ti.com
J7200 has a single instance of 8 channel ADC in MCU domain. Add DT node
for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20201029050950.4500-1-vigneshr@ti.com
Two carveout reserved memory nodes each have been added for each of the
R5F remote processor devices within both the MCU and MAIN domains for the
TI J721E EVM 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 device, and the second region will furnish the static carveout
regions for the firmware memory.
The current carveout addresses and sizes are defined statically for each
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 either
to allocate the memory for firmware memory segments.
Note that the R5F1 carveouts are needed only if the R5F cluster is running
in Split (non-LockStep) mode. The reserved memory nodes can be disabled
later on if there is no use-case defined to use the corresponding
remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-9-s-anna@ti.com
Add the required 'mboxes' property to all the R5F processors for the
TI J721E common processor board. 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 nodes are therefore
added in the common k3-j721e-som-p0.dtsi file so that all of these can
be co-located.
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>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-8-s-anna@ti.com
The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. 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). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.
Add the DT nodes for these two MAIN domain R5F cluster/subsystems,
the two R5F cores are each added as child nodes to the corresponding
main cluster node. Both the clusters are configured to run in LockStep
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 needed:
MAIN R5FSS0 Core0: j7-main-r5f0_0-fw (both in LockStep and Split modes)
MAIN R5FSS0 Core1: j7-main-r5f0_1-fw (needed only in Split mode)
MAIN R5FSS1 Core0: j7-main-r5f1_0-fw (both in LockStep and Split modes)
MAIN R5FSS1 Core1: j7-main-r5f1_1-fw (needed only in Split mode)
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-7-s-anna@ti.com
The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. 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). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.
Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5F cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in LockStep 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 needed:
MCU R5FSS0 Core0: j7-mcu-r5f0_0-fw (both in LockStep and Split modes)
MCU R5FSS0 Core1: j7-mcu-r5f0_1-fw (needed only in Split mode)
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-6-s-anna@ti.com
Add a reserved memory node to reserve a portion of the DDR memory to be
used for performing inter-processor communication between all the MCU R5F
remote processors running RTOS on all the TI AM654 boards. This memory
shall be exercised only if the MCU R5FSS cluster is configured for Split
mode. A single 1 MB of memory at 0xa2000000 is reserved for this purpose,
and this accounts for all the vrings and vring buffers between pair of
these R5F remote processors.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-5-s-anna@ti.com
The R5F processors do not have an MMU, and as such require the exact memory
used by the firmwares to be set-aside. Four carveout reserved memory nodes
have been added with two each (1 MB and 15 MB in size) used for each of the
MCU R5F remote processor devices on all the TI K3 AM65x boards. These nodes
are assigned to the respective rproc device nodes as well.
The current carveout addresses and sizes are defined statically for each
device. The first region will be used as the DMA pool for the rproc
device, and the second region will furnish the static carveout regions
for the firmware memory.
Note that the R5F1 carveouts are needed only if the corresponding R5F
cluster is running in Split (non-LockStep) mode. The corresponding
reserved memory nodes can be disabled later on if there is no use-case
defined to use the corresponding remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-4-s-anna@ti.com
Add the required 'mboxes' property to both the R5F processors on all the
TI K3 AM65x 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 the R5F Core1 resources are needed and used only when the
R5F cluster is configured for Split-mode.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-3-s-anna@ti.com
The AM65x SoCs have a single dual-core Arm Cortex-R5F processor (R5FSS)
subsystem/cluster. This R5F cluster (MCU_R5FSS0) is present within the
MCU domain, and can be configured at boot time to be either run in a
LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in
Split-mode. This subsystem has 64 KB each Tightly-Coupled Memory (TCM)
internal memories for each core split between two banks - TCMA and TCMB
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5F clusters such as the absence of an ACP
port, presence of an additional TI-specific Region Address Translater
(RAT) module for translating 32-bit CPU addresses into larger system
bus addresses etc.
Add the DT node for this R5F cluster/subsystem, the two R5F cores are
added as child nodes to the main cluster node. The cluster is configured
to run in LockStep 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 A53 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 needed:
am65x-mcu-r5f0_0-fw (LockStep mode and for Core0 in Split mode)
am65x-mcu-r5f0_1-fw (Core1 in Split mode)
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20201029033802.15366-2-s-anna@ti.com
DSS is IO coherent on AM65, so we should mark it as such with
'dma-coherent' property in the DT file.
Fixes: fc539b90ed ("arm64: dts: ti: am654: Add DSS node")
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Cc: stable@vger.kernel.org # v5.8+
Link: https://lore.kernel.org/r/20201102134650.55321-1-tomi.valkeinen@ti.com
The board uses lane 3 of SERDES for USB. Set the mux
accordingly.
The USB controller and EVM supports super-speed for USB0
on the Type-C port. However, the SERDES has a limitation
that upto 2 protocols can be used at a time. The SERDES is
wired for PCIe, QSGMII and USB super-speed. It has been
chosen to use PCI2 and QSGMII as default. So restrict
USB0 to high-speed mode.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-7-rogerq@ti.com
First two lanes of SERDES is connected to PCIe, third lane is
connected to QSGMII and the last lane is connected to USB. However,
Cadence torrent SERDES doesn't support more than 2 protocols
at the same time. Configure it only for PCIe and QSGMII.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-6-rogerq@ti.com
The USB controller can be connected to one of the 2 lanes
of SERDES0 using a MUX. Add a MUX controller node for that.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-4-rogerq@ti.com
The SERDES lane control mux registers are present in the
CTRLMMR space.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200930122032.23481-3-rogerq@ti.com
The convention for node names is to use hyphens, not underscores.
dtschema for pca95xx expects GPIO hogs to end with 'hog' prefix.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200916155715.21009-7-krzk@kernel.org
Add support for the eMMC and SD card connected on the common
processor board
sdhci0 is connected to an eMMC while sdhci1 is connected to the
micro SD slot.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20200924112644.11076-3-faiz_abbas@ti.com
Add support for MMC/SD controller nodes present on TI's j7200 SoCs.
There are two nodes:
1. sdhci0 (8 bit bus width, 200 MHz, HS200, 200 MBps)
2. sdhci1 (4 bit bus width, 50 MHz, HS, 25 MBps)
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20200924112644.11076-2-faiz_abbas@ti.com
J7200 SoM has a HyperFlash connected to HyperBus memory controller. But
HyperBus is muxed with OSPI, therefore keep HyperBus node disabled.
Bootloader will detect the mux and enable the node as required.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20200923163150.16973-3-vigneshr@ti.com
J7200 has a Flash SubSystem that has one OSPI and one HyperBus.. Add
DT nodes for HyperBus controller for now.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Link: https://lore.kernel.org/r/20200923163150.16973-2-vigneshr@ti.com
Add DT nodes for I2C GPIO expanders on main_i2c0 and main_i2c1 and
also add the pinmux corresponding to these I2C instances.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Reviewed-by: Faiz Abbas <faiz_abbas@ti.com>
Link: https://lore.kernel.org/r/20200923155400.13757-3-vigneshr@ti.com
J7200 has 7 I2Cs in main domain, 2 I2Cs in MCU and 1 in wakeup domain.
Add DT nodes for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Reviewed-by: Faiz Abbas <faiz_abbas@ti.com>
Link: https://lore.kernel.org/r/20200923155400.13757-2-vigneshr@ti.com
The TI J7200 EVM base board has TI DP83867 PHY connected to external CPSW
NUSS Port 1 in rgmii-rxid mode.
Hence, add pinmux and Ethernet PHY configuration for TI J7200 SoC MCU
Gigabit Ethernet two ports Switch subsystem (CPSW NUSS).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200923220938.30788-5-grygorii.strashko@ti.com
Add the ringacc and udmap nodes for Main and MCU NAVSS.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200923220938.30788-2-grygorii.strashko@ti.com
Add support for J7200 Common Processor Board.
The EVM architecture is very similar to J721E 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 has most of the actual
connectors, power supply etc. A SOM (System on Module) is plugged on
to the common processor board and this contains the SoC, PMIC, DDR and
basic high speed components necessary for functionality.
Note:
* The minimum configuration required to boot up the board is System On
Module(SOM) + Common Processor Board.
* Since there is just a single SOM and Common Processor Board, we are
maintaining common processor board as the base dts and SOM as the dtsi
that we include. In the future as more SOM's appear, we should move
common processor board as a dtsi and include configurations as dts.
* All daughter cards beyond the basic boards shall be maintained as
overlays.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200914162231.2535-6-lokeshvutla@ti.com
The J7200 SoC is a part of the K3 Multicore SoC architecture platform.
It is targeted for automotive gateway, vehicle compute systems,
Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications.
The SoC aims to meet the complex processing needs of modern embedded
products.
Some highlights of this SoC are:
* Dual Cortex-A72s in a single cluster, two clusters of lockstep
capable dual Cortex-R5F MCUs and a Centralized Device Management and
Security Controller (DMSC).
* Configurable L3 Cache and IO-coherent architecture with high data
throughput capable distributed DMA architecture under NAVSS.
* Integrated Ethernet switch supporting up to a total of 4 external ports
in addition to legacy Ethernet switch of up to 2 ports.
* Upto 1 PCIe-GEN3 controller, 1 USB3.0 Dual-role device subsystems,
20 MCANs, 3 McASP, eMMC and SD, OSPI/HyperBus memory controller, I3C
and I2C, eCAP/eQEP, eHRPWM among other peripherals.
* One hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
management.
See J7200 Technical Reference Manual (SPRUIU1, June 2020)
for further details: https://www.ti.com/lit/pdf/spruiu1
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20200914162231.2535-5-lokeshvutla@ti.com
J721E Common Processor Board has PCIe connectors for the 1st three PCIe
instances. Configure the three PCIe instances in RC mode and disable the
4th PCIe instance.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200914152115.1788-3-kishon@ti.com
Add PCIe device tree nodes (both RC and EP) for the four
PCIe instances here.
Also add the missing translations required in the "ranges"
DT property of cbass_main to access all the four PCIe
instances.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200914152115.1788-2-kishon@ti.com
We intend to use one header file for SERDES MUX for all
TI SoCs so rename the header file.
The exsting macros are too generic. Prefix them with SoC name.
While at that, add the missing configurations for completeness.
Fixes: b766e3b0d5 ("arm64: dts: ti: k3-j721e-main: Add system controller node and SERDES lane mux")
Reported-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200918165930.2031-1-rogerq@ti.com
Building with W=2 throws up a bunch of easy to fixup warnings..
node_name_chars_strict is one of them.. Knock those out.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200903130015.21361-9-nm@ti.com
serdes and ehrpwm_tbclk nodes should be using clock@ naming for nodes
following standard conventions of device tree (section 2.2.2 Generic
Names recommendation in [1]).
[1] https://github.com/devicetree-org/devicetree-specification/tree/v0.3
Suggested-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200903130015.21361-5-nm@ti.com
Per errata i2104 documented in AM65x device errata document (TI document
number SPRZ452E, revised June 2019), Gen3 operation is not supported for
both PCIe Root Complex and Endpoint modes of operation.
See: https://www.ti.com/lit/er/sprz452e/sprz452e.pdf
Restrict speed to Gen2 to address the errata.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200802165356.10285-1-nsekhar@ti.com
Add a reserved memory node to reserve a portion of the DDR memory to be
used for performing inter-processor communication between all the remote
processors running RTOS on the TI J721E EVM boards. 28 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.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200825172145.13186-9-s-anna@ti.com
Two carveout reserved memory nodes have been added for the lone C71x DSP
remote processor device present within the MAIN voltage domain for the TI
J721E EVM boards. These nodes are assigned to the respective rproc device
node as well. The first region will be used as the DMA pool for the rproc
device, and the second region will furnish the static carveout regions for
the firmware memory.
The current carveout addresses and sizes are defined statically for each
device. 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 currently do not need any
RSC_CARVEOUT entries either in their resource tables to allocate the
memory for firmware memory segments.
The reserved memory nodes can be disabled later on if there is no use-case
defined to use the C71x DSP remoteproc processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200825172145.13186-8-s-anna@ti.com
Add the required 'mboxes' property to the C71x DSP processor for the TI
J721E common processor board. The mailboxes and some shared memory are
required for running the Remote Processor Messaging (RPMsg) stack between
the host processor and each of the DSPs. The nodes are therefore added
in the common k3-j721e-som-p0.dtsi file so that all of these can be
co-located.
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.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200825172145.13186-7-s-anna@ti.com
The J721E SoCs have a single TMS320C71x DSP Subsystem in the MAIN
voltage domain containing the next-generation C711 CPU core. The
subsystem has 32 KB of L1D configurable SRAM/Cache and 512 KB of
L2 configurable SRAM/Cache. This subsystem has a CMMU but is not
used currently. The inter-processor communication between the main
A72 cores and the C711 processor is achieved through shared memory
and a Mailbox. Add the DT node for this DSP processor sub-system
in the common k3-j721e-main.dtsi file.
The following firmware name is used by default for the C71x core,
and can be overridden in a board dts file if desired:
C71x_0 DSP: j7-c71_0-fw
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200825172145.13186-6-s-anna@ti.com
Two carveout reserved memory nodes each have been added for each of the
C66x DSP remote processor devices present within the MAIN voltage domain
for the TI J721E EVM 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.
The minimum granularity on the Cache settings on C66x DSP cores is 16 MB,
so the DMA memory regions are chosen such that they are in separate 16 MB
regions for each DSP, while reserving a total of 16 MB for each DSP and
not changing the overall DSP remoteproc carveouts.
The current carveout addresses and sizes are defined statically for each
device. The C66x DSP 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.
The reserved memory nodes can be disabled later on if there is no use-case
defined to use the corresponding remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200825172145.13186-5-s-anna@ti.com
Add the required 'mboxes' property to both the C66x DSP processors for the
TI J721E common processor board. The mailboxes and some shared memory are
required for running the Remote Processor Messaging (RPMsg) stack between
the host processor and each of the DSPs. The nodes are therefore added
in the common k3-j721e-som-p0.dtsi file so that all of these can be
co-located.
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.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200825172145.13186-4-s-anna@ti.com
The J721E SoCs have two TMS320C66x DSP Core Subsystems (C66x CorePacs)
in the MAIN voltage domain, each with a C66x Fixed/Floating-Point DSP
Core, and 32 KB of L1P & L1D configurable SRAMs/Cache and an additional
288 KB of L2 configurable SRAM/Cache. These subsystems do not have
an MMU but contain a Region Address Translator (RAT) sub-module for
translating 32-bit processor addresses into larger bus addresses.
The inter-processor communication between the main A72 cores and
these processors is achieved through shared memory and Mailboxes.
Add the DT nodes for these DSP processor sub-systems in the common
k3-j721e-main.dtsi file.
The following firmware names are used by default for these cores, and
can be overridden in a board dts file if desired:
C66x_0 DSP: j7-c66_0-fw
C66x_1 DSP: j7-c66_1-fw
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200825172145.13186-3-s-anna@ti.com
The commit eb9f9173d0 ("arm64: dts: ti: k3-j721e-common-proc-board:
Add IPC sub-mailbox nodes") has added the sub-mailbox nodes used by
various remote processors and disabled the unused mailbox clusters
directly in the k3-j721e-common-proc-board dts file. Move all of these
nodes into the k3-j721e-som-p0.dtsi file instead to co-locate all the
mailboxes and the soon to be added DDR reserved-memory carveout nodes
used by remoteprocs within the same dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200825172145.13186-2-s-anna@ti.com
The various CBASS interconnect nodes on K3 J721E SoCs are defined
using the node name "interconnect". This is not a valid node name
as per the dt-schema. Fix these node names to use the standard name
used for SoC interconnects, "bus".
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200723211137.26641-3-s-anna@ti.com
The various CBASS interconnect nodes on K3 AM65x SoCs are defined
using the node name "interconnect". This is not a valid node name
as per the dt-schema. Fix these node names to use the standard name
used for SoC interconnects, "bus".
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20200723211137.26641-2-s-anna@ti.com
Update the ringacc and udma dt nodes to use the latest RM resource types
similar to the ones used in k3-j721e dt nodes.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200806074826.24607-14-lokeshvutla@ti.com
Update the INTA and INTR dt nodes to the latest DT bindings.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200806074826.24607-13-lokeshvutla@ti.com
The Type-C compainon chip on the board needs ~133ms (tCCB_DEFAULT)
to debounce the CC lines in order to detect attach and plug orientation
and reflect the correct DIR status. [1]
On the EVM however we need to wait upto 700ms before sampling the
Type-C DIR line else we can get incorrect direction state.
[1] http://www.ti.com/lit/ds/symlink/tusb321.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
USB0 supports super-speed mode on the EVM. Enable that.
On the EVM, USB0 uses SERDES3 for super-speed lane.
Since USB0 is a type-C port, it needs to support lane swapping
for cable flip support. This is provided using SERDES lane
swap feature. Provide the Type-C cable orientation GPIO
to the SERDES Wrapper driver.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The USB controllers can be connected to one of the 2 SERDESes
using a MUX. Add a MUX controller node fot that.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The system controller node manages the CTRL_MMR0 region.
Add serdes_ln_ctrl node which is used for controlling the SERDES lane mux.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add DT nodes for all instances of WIZ and SERDES modules.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The preferable name for gic-its is msi-controller, so rename it to fix
dtbs_check warning:
k3-j721e-common-proc-board.dt.yaml: interrupt-controller@1800000:
gic-its@1820000: False schema does not allow {'compatible':
['arm,gic-v3-its'], 'reg': [[0, 25296896, 0, 65536]],
'socionext,synquacer-pre-its': [[16777216, 4194304]], 'msi-controller':
True, '#msi-cells': [[1]]}
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Rename smmu node to iommu to fix dtbs_check warning:
k3-j721e-common-proc-board.dt.yaml: smmu@36600000: $nodename:0: 'smmu@36600000' does not match '^iommu@[0-9a-f]*'
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With silicon revision 2.0, add support for SD card on the am65x-evm.
Boards with silicon revision 1.0 are susceptible to interface issues
because of erratas i2025 and i2026[1] and are recommended to disable
this node.
[1] Am654x Silicon Revision 1.0 errata: https://www.ti.com/lit/pdf/sprz452
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add support for the 2nd SDHCI controller on TI's AM654x SoCs.
Although it supports upto SDR104 (100 MBps @ 200 MHz) speed mode,
only enable support upto High Speed (25 MBps @ 50 MHz) for now.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The codec is wired in multi DIN/DOUT setup (DIN1/2/3/4/DOUT1/2/3 is
connected to McASP serializer).
To support wide range of audio features a generic sound card can not be
used since we need to use different reference clock source for 44.1 and
48 KHz family of sampling rates.
Depending on the sample size we also need to use different slot width to
be able to support 16 and 24 bits.
There are couple of notable difference compared to DIN1/DOUT1 mode:
the channel mapping is 'random' for first look compared to the single
serializer setup:
_ _ _
|o|c1 |o|p1 |o|p3
_ | | | | | |
|o|c3 |o|c2 |o|p4 |o|p2
------------------------
c1/2/3 - capture jacks (3rd is line)
p1/2/3/4 - playback jacks (4th is line)
2 channel audio (stereo):
0 (left): p1/c1 left
1 (right): p1/c1 right
4 channel audio:
0: p1/c1 left
1: p2/c2 left
2: p1/c1 right
3: p2/c2 right
6 channel audio
0: p1/c1 left
1: p2/c2 left
2: p3/c3 left
3: p1/c1 right
4: p2/c2 right
5: p3/c3 right
8 channel audio
0: p1/c1 left
1: p2/c2 left
2: p3/c3 left
3: p4 left
4: p1/c1 right
5: p2/c2 right
6: p3/c3 right
7: p4 right
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Two pimux entry is present with the same name, remove one of them.
Fixes: cb27354b38 ("arm64: dts: ti: k3-j721e: Add DT nodes for few peripherials")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
According to the latest AM65x Data Manual[1], a different output tap
delay value is optimum for a given speed mode. Update these values.
[1] http://www.ti.com/lit/gpn/am6526
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
This is the set of device tree changes, mostly covering new
hardware support, with 577 patches touching a little over 500
files.
There are five new Arm SoCs supported in this release, all of
them for existing SoC families:
- Realtek RTD1195, RTD1395 and RTD1619 -- three SoCs used in
both NAS devices and Android Set-top-box designs, along
with the "Horseradish", "Lion Skin" and "Mjolnir" reference
platforms; the Mele X1000 and Xnano X5 set-top-boxes and
the Banana Pi BPi-M4 single-board computer.
- Renesas RZ/G1H (r8a7742) -- a high-end 32-bit industrial SoC
and the iW-RainboW-G21D-Qseven-RZG1H board/SoM
- Rockchips RK3326 -- low-end 64-bit SoC along with the
Odroid-GO Advance game console
Newly added machines on already supported SoCs are:
- AMLogic S905D based Smartlabs SML-5442TW TV box
- AMLogic S905X3 based ODROID-C4 SBC
- AMLogic S922XH based Beelink GT-King Pro TV box
- Allwinner A20 based Olimex A20-OLinuXino-LIME-eMMC SBC
- Aspeed ast2500 based BMCs in Facebook x86 "Yosemite V2"
and YADRO OpenPower P9 "Nicole"
- Marvell Kirkwood based Check Point L-50 router
- Mediatek MT8173 based Elm/Hana Chromebook laptops
- Microchip SAMA5D2 "Industrial Connectivity Platform"
reference board
- NXP i.MX8m based Beacon i.MX8m-Mini SoM development kit
- Octavo OSDMP15x based Linux Automation MC-1 development board
- Qualcomm SDM630 based Xiaomi Redmi Note 7 phone
- Realtek RTD1295 based Xnano X5 TV Box
- STMicroelectronics STM32MP1 based Stinger96 single-board
computer and IoT Box
- Samsung Exynos4210 based based Samsung Galaxy S2 phone
- Socionext Uniphier based Akebi96 SBC
- TI Keystone based K2G Evaluation board
- TI am5729 based Beaglebone-AI development board
Include device descriptions for additional hardware support in existing
SoCs and machines based on all major SoC platforms:
- AMlogic Meson
- Allwinner sunxi
- Arm Juno/VFP/Vexpress/Integrator
- Broadcom bcm283x/bcm2711
- Hisilicon hi6220
- Marvell EBU
- Mediatek MT27xx, MT76xx, MT81xx and MT67xx
- Microchip SAMA5D2
- NXP i.MX6/i.MX7/i.MX8 and Layerscape
- Nvidia Tegra
- Qualcomm Snapdragon
- Renesas r8a77961, r8a7791
- Rockchips RK32xx/RK33xx
- ST-Ericsson ux500
- STMicroelectronics SMT32
- Samsung Exynos and S5PV210
- Socionext Uniphier
- TI OMAP5/DRA7 and Keystone
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAl7ZWskACgkQmmx57+YA
GNl60xAAtW8fmOerc1JvUSNZFN6PApVexhNUDPnc0Wytzsi67v9KKTz7CNxEaO6z
o466PfCObhi8IlLa1NmJxhSRXjv84JnbUODkiLeWhpX3HWE4rWhVz+/+gukmIah4
H8Q3ehLyatgsGopXwBWShKoQmls2H4v9ETxKwx60Yj/HKqZeay7SLmLXbZ0SvFmZ
5kkROmXiFg5iWjtALuibJWCsG1o5Hsfl8JMiPsr3W+O2hTmm4AvJ3ESkCFeqqJ1M
ccxTEaFhakM/U6xujQYG/mSbRox6mnxZukYzQLh+K0ccP7yvS5J90GOE3B7hNDFy
qZiB6hfrX6Rmcr7k0nhAzTDOOfHF+DmikGTKh9BvpOenklhHu9AYQlZwh5gK3Svw
G5T3mAKMd3YF4ywJHNUKtzVPp/Q786CXq08PdAY+tDiLo02UIR5WjOQ9at2JJKDG
bfUQClyii+EtOqgOTmIPH2yUsYgVsbbv4F7SPk/c4BEn5od9a+bLoIne7yu8sy6M
IdW8klUtoswzmH9lGlOjUic4pMrRVY+8gSgtETSF0sePoapcQUJg6gEEygvj4H36
BWFVHJK0WGQ2PWb3HHqRa20PJ92Jn65p1uK0eox4qkxd24KgpV6l2aAfx7FMUw47
vqxb59ogFsC+XIZ5OSG0fYfejnwgfTSJLodrJrk9UdvXb6nwo/Q=
=17kt
-----END PGP SIGNATURE-----
Merge tag 'arm-dt-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM devicetree updates from Arnd Bergmann:
"This is the set of device tree changes, mostly covering new hardware
support, with 577 patches touching a little over 500 files.
There are five new Arm SoCs supported in this release, all of them for
existing SoC families:
- Realtek RTD1195, RTD1395 and RTD1619 -- three SoCs used in both NAS
devices and Android Set-top-box designs, along with the
"Horseradish", "Lion Skin" and "Mjolnir" reference platforms; the
Mele X1000 and Xnano X5 set-top-boxes and the Banana Pi BPi-M4
single-board computer.
- Renesas RZ/G1H (r8a7742) -- a high-end 32-bit industrial SoC and
the iW-RainboW-G21D-Qseven-RZG1H board/SoM
- Rockchips RK3326 -- low-end 64-bit SoC along with the Odroid-GO
Advance game console
Newly added machines on already supported SoCs are:
- AMLogic S905D based Smartlabs SML-5442TW TV box
- AMLogic S905X3 based ODROID-C4 SBC
- AMLogic S922XH based Beelink GT-King Pro TV box
- Allwinner A20 based Olimex A20-OLinuXino-LIME-eMMC SBC
- Aspeed ast2500 based BMCs in Facebook x86 "Yosemite V2" and YADRO
OpenPower P9 "Nicole"
- Marvell Kirkwood based Check Point L-50 router
- Mediatek MT8173 based Elm/Hana Chromebook laptops
- Microchip SAMA5D2 "Industrial Connectivity Platform" reference
board
- NXP i.MX8m based Beacon i.MX8m-Mini SoM development kit
- Octavo OSDMP15x based Linux Automation MC-1 development board
- Qualcomm SDM630 based Xiaomi Redmi Note 7 phone
- Realtek RTD1295 based Xnano X5 TV Box
- STMicroelectronics STM32MP1 based Stinger96 single-board computer
and IoT Box
- Samsung Exynos4210 based based Samsung Galaxy S2 phone
- Socionext Uniphier based Akebi96 SBC
- TI Keystone based K2G Evaluation board
- TI am5729 based Beaglebone-AI development board
Include device descriptions for additional hardware support in
existing SoCs and machines based on all major SoC platforms:
- AMlogic Meson
- Allwinner sunxi
- Arm Juno/VFP/Vexpress/Integrator
- Broadcom bcm283x/bcm2711
- Hisilicon hi6220
- Marvell EBU
- Mediatek MT27xx, MT76xx, MT81xx and MT67xx
- Microchip SAMA5D2
- NXP i.MX6/i.MX7/i.MX8 and Layerscape
- Nvidia Tegra
- Qualcomm Snapdragon
- Renesas r8a77961, r8a7791
- Rockchips RK32xx/RK33xx
- ST-Ericsson ux500
- STMicroelectronics SMT32
- Samsung Exynos and S5PV210
- Socionext Uniphier
- TI OMAP5/DRA7 and Keystone"
* tag 'arm-dt-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (564 commits)
ARM: dts: keystone: Rename "msmram" node to "sram"
arm: dts: mt2712: add uart APDMA to device tree
arm64: dts: mt8183: add mmc node
arm64: dts: mt2712: add ethernet device node
arm64: tegra: Make the RTC a wakeup source on Jetson Nano and TX1
ARM: dts: mmp3: Add the fifth SD HCI
ARM: dts: berlin*: Fix up the SDHCI node names
ARM: dts: mmp3: Fix USB & USB PHY node names
ARM: dts: mmp3: Fix L2 cache controller node name
ARM: dts: mmp*: Fix up encoding of the /rtc interrupts property
ARM: dts: pxa*: Fix up encoding of the /rtc interrupts property
ARM: dts: pxa910: Fix the gpio interrupt cell number
ARM: dts: pxa3xx: Fix up encoding of the /gpio interrupts property
ARM: dts: pxa168: Fix the gpio interrupt cell number
ARM: dts: pxa168: Add missing address/size cells to i2c nodes
ARM: dts: dove: Fix interrupt controller node name
ARM: dts: kirkwood: Fix interrupt controller node name
arm64: dts: Add SC9863A emmc and sd card nodes
arm64: dts: Add SC9863A clock nodes
arm64: dts: mt6358: add PMIC MT6358 related nodes
...
Update CPTS node following DT binding update:
- add reg and compatible properties
- fix node name
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add DT node for Main NAVSS CPTS module.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add DT node for The TI J721E MCU CPSW CPTS which is part of MCU CPSW NUSS.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add DT node for Main NAVSS CPTS module.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add DT node for the TI AM65x SoC Common Platform Time Sync (CPTS).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add DT nodes for all ehrpwm instances present on AM654 EVM.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The am654 SoC has three thermal zones namely MPU0, MPU1 and MCU
zones.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
VTM stands for voltage and thermal management.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The DSS related clock muxes are set via assigned-clocks in a way which
provides us:
VP0 - DisplayPort SST
VP1 - DPI0
VP2 - DSI
VP3 - DPI1
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add DSS node to k3-am65-main.dtsi with labels for board specific
support and syscon node for oldi-io-ctrl.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Most of the commits are for additional hardware support and minor fixes
for existing machines for all the usual platforms: qcom, amlogic, at91,
gemini, mediatek, ti, socfpga, i.mx, layerscape, uniphier, rockchip,
exynos, ux500, mvebu, tegra, stm32, renesas, sunxi, broadcom, omap,
and versatile.
The conversion of binding files to machine-readable yaml format
continues, along with fixes found during the validation.
Andre Przywara takes over maintainership for the old Calxeda Highbank
platform and provides a number of updates.
The OMAP2+ platforms see a continued move from platform data into
dts files, for many devices that relied on a mix of auxiliary data
in addition to the DT description
A moderate number of new SoCs and machines are added, here is a full
list:
- Two new Qualcomm SoCs with their evaluation boards: Snapdragon 865
(SM8250) is the current high-end phone chip, and IPQ6018 is a new
WiFi-6 router chip.
- Mediatek MT8516 application processor SoC for voice assistants, along
with the "pumpkin" development board
- NXP i.MX8M Plus SoC, a variant of the popular i.MX8M, along with an
evaluation board.
- Kontron "sl28" board family based on NXP LS1028A
- Eleven variations of the new i.MX6 TechNexion Pico board, combining
the "dwarf", "hobbit", "nymph" and "pi" baseboards with i.MX6/i.MX7
SoM carriers
- Three additional variants of the Toradex Colibri board family, all
based on versions of the NXP i.MX7.
- The Pinebook Pro laptop based on Rockchip RK3399
- Samsung S7710 Galaxy Xcover 2, a 2013 vintage Android phone based on
the ST-Ericsson u8500 platform
- DH Electronics DHCOM SoM and PDK2 rev. 400 carrier based on
STMicroelectronics stm32mp157
- Renesas M3ULCB starter kit for R-Car M3-W+
- Hoperun HiHope development board with Renesas RZ/G2M
- Pine64 PineTab tablet and PinePhone phone, both based on Allwinner A64
- Linutronix Testbox v2 for the Lamobo R1 router, based on Allwinner A20
- PocketBook Touch Lux 3 ebook reader, based on Allwinner A13
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAl6HpMkACgkQmmx57+YA
GNkGsQ/+KRbE74XGQvZww5PleaesqoZZhrt2gbi0pEJZ/JTgNa3dBkT+JwlToe/H
x7nFVfMZeEl4O9GO0+/CH2tsmQa5BA8R9JddhFxwnZ48ZYLQAdaukwt94LM2zj3K
GFgs47N4DAAF5QJoXNtmmQCXUWbj7A/0S5TTpXe94TYPN9XiJCdsyNNLpW3undTe
K1HLnd4yWGforQc/VfRsV/Gsqi1VNHgL34M3belahiG7x0lytJDCHfhsfmIdxdGR
n3LVRRJr6NhKcuUw3XtA8MxT4dTAcgHjbbDLkS/b1nHfuXMi0/zW8VPBzD/xyHL7
fbFl8ayUMANB6FD/U7ptUC/0IMXuHDUn4B60CEEzK8ddkEbErrmXlYVGogpFHxvm
MqrW8CnO0YEr0YMNAIyZoqHYGq8+8DCq+SRH48brdPzuiKI6OahdV1o07ulGhOjq
ihwoZNE+J0NjeaX7C1xBX3DT1XqdcNPCmu3gx6r06u2FVXVm1J19YkIzQnEXQvKy
NRIw5LIOfEsxkMSQ0oUuAUUUY1Fq1zuHqD8MmgBd3jqIULQqgfahmPL6Dtwm5QFf
R17YsMcQ7ae1Pp7a+D3Jrkbn+s2y8wmJZIqH3eWebps9RvpWmrxzsRfOJ2czhqM1
NY7Z/TGMM7lGM75DZ+xskfk7UCAX+hqMSTiNg9xbRo8946GAbV4=
=ye2F
-----END PGP SIGNATURE-----
Merge tag 'arm-dt-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM devicetree updates from Arnd Bergmann:
"Most of the commits are for additional hardware support and minor
fixes for existing machines for all the usual platforms: qcom,
amlogic, at91, gemini, mediatek, ti, socfpga, i.mx, layerscape,
uniphier, rockchip, exynos, ux500, mvebu, tegra, stm32, renesas,
sunxi, broadcom, omap, and versatile.
The conversion of binding files to machine-readable yaml format
continues, along with fixes found during the validation. Andre
Przywara takes over maintainership for the old Calxeda Highbank
platform and provides a number of updates.
The OMAP2+ platforms see a continued move from platform data into dts
files, for many devices that relied on a mix of auxiliary data in
addition to the DT description
A moderate number of new SoCs and machines are added, here is a full
list:
- Two new Qualcomm SoCs with their evaluation boards: Snapdragon 865
(SM8250) is the current high-end phone chip, and IPQ6018 is a new
WiFi-6 router chip.
- Mediatek MT8516 application processor SoC for voice assistants,
along with the "pumpkin" development board
- NXP i.MX8M Plus SoC, a variant of the popular i.MX8M, along with an
evaluation board.
- Kontron "sl28" board family based on NXP LS1028A
- Eleven variations of the new i.MX6 TechNexion Pico board, combining
the "dwarf", "hobbit", "nymph" and "pi" baseboards with i.MX6/i.MX7
SoM carriers
- Three additional variants of the Toradex Colibri board family, all
based on versions of the NXP i.MX7.
- The Pinebook Pro laptop based on Rockchip RK3399
- Samsung S7710 Galaxy Xcover 2, a 2013 vintage Android phone based
on the ST-Ericsson u8500 platform
- DH Electronics DHCOM SoM and PDK2 rev. 400 carrier based on
STMicroelectronics stm32mp157
- Renesas M3ULCB starter kit for R-Car M3-W+
- Hoperun HiHope development board with Renesas RZ/G2M
- Pine64 PineTab tablet and PinePhone phone, both based on Allwinner
A64
- Linutronix Testbox v2 for the Lamobo R1 router, based on Allwinner
A20
- PocketBook Touch Lux 3 ebook reader, based on Allwinner A13"
* tag 'arm-dt-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (520 commits)
ARM: dts: ux500: Fix missing node renames
arm64: dts: Revert "specify console via command line"
MAINTAINERS: Update Calxeda Highbank maintainership
arm: dts: calxeda: Group port-phys and sgpio-gpio items
arm: dts: calxeda: Fix interrupt grouping
arm: dts: calxeda: Provide UART clock
arm: dts: calxeda: Basic DT file fixes
arm64: dts: specify console via command line
ARM: dts: at91: sama5d27_wlsom1_ek: add USB device node
ARM: dts: gemini: Add thermal zone to DIR-685
ARM: dts: gemini: Rename IDE nodes
ARM: socfpga: arria10: Add ptp_ref clock to ethernet nodes
arm64: dts: ti: k3-j721e-mcu: add scm node and phy-gmii-sel nodes
arm64: dts: ti: k3-am65-mcu: add phy-gmii-sel node
arm64: dts: ti: k3-am65-mcu: Add DMA entries for ADC
arm64: dts: ti: k3-am65-main: Add DMA entries for main_spi0
arm64: dts: ti: k3-j721e-mcu-wakeup: Add DMA entries for ADC
arm64: dts: ti: k3-am65: Add clocks to dwc3 nodes
arm64: dts: meson-g12b-odroid-n2: add SPIFC controller node
arm64: dts: khadas-vim3: add SPIFC controller node
...
The TI J721E EVM base board has TI DP83867 PHY connected to external CPSW
NUSS Port 1 in rgmii-rxid mode.
Hence, add pinmux and Ethernet PHY configuration for TI j721e SoC MCU
Gigabit Ethernet two ports Switch subsystem (CPSW NUSS).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Murali Karicheri <m-karicheri2@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add DT node for The TI J721E MCU SoC Gigabit Ethernet
subsystem (MCU CPSW NUSS).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Murali Karicheri <m-karicheri2@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
AM654 EVM base board has TI DP83867 PHY connected to external CPSW NUSS
Port 1 in rgmii-rxid mode.
Hence, add pinmux and Ethernet PHY configuration for TI am654 SoC Gigabit
Ethernet two ports Switch subsystem (CPSW NUSS).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Murali Karicheri <m-karicheri2@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add DT node for the TI AM65x SoC Gigabit Ethernet two ports Switch
subsystem (CPSW NUSS).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Murali Karicheri <m-karicheri2@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add DT node for MCU System Control module DT node and DT node for the TI
J721E SoC phy-gmii-sel PHY required for Ethernet ports mode selection.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add DT node for the TI AM65x SoC phy-gmii-sel PHY required for Ethernet
ports mode selection.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add DMA entry for main_spi0, that has SPI flash connected, for better
throughput and reduced CPU load.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The TI sci-clk driver can scan the DT for all clocks provided by system
firmware and does this by checking the clocks property of all nodes, so
we must add this to the dwc3 nodes so USB clocks are available.
Without this USB does not work with latest system firmware i.e.
[ 1.714662] clk: couldn't get parent clock 0 for /interconnect@100000/dwc3@4020000
Fixes: cc54a99464 ("arm64: dts: ti: k3-am6: add USB suppor")
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Cc: stable@kernel.org
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add support for the OV5640 CSI camera:
- add the OV5640 nodes
- add the CAL node linkage
- enable CAL node
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add CAL dtsi node for AM654 device. Including proper power-domains and
clock properties.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the nodes for McASP 0-11 and keep them disabled because several
required properties are not present as they are board specific.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the nodes for McASP 0-2 and keep them disabled because several
required properties are not present as they are board specific.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the ringacc and udmap nodes for main and mcu NAVSS.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Secure proxy (NAVSS0_SEC_PROXY0) and smmu (NAVSS0_TCU) is part of the
Navigator Subsystem.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
NAVSS is a subsystem containing different IPs, it is not really a bus.
Change the compatible from "simple-bus" to "simple-mfd" to reflect that.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
On am654 the MAIN NAVSS base address was 0x30800000, but in j721e it is
at 0x30000000
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the ringacc and udmap nodes for main and mcu NAVSS.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Secure proxy (NAVSS0_SEC_PROXY0) is part of the Navigator Subsystem.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
NAVSS is a subsystem containing different IPs, it is not really a bus.
Change the compatible from "simple-bus" to "simple-mfd" to reflect that.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add power-domains entry for smmu, so that the it is accessible as long
as the driver is active. Without this device shutdown is throwing the
below warning:
"[ 44.736348] arm-smmu-v3 36600000.smmu: failed to clear cr0"
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The MCU System control module support is added to the device tree to allow
drivers to access to their System control module registers.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add IRQ line for IO expander present on wkup_i2c bus on AM654 EVM
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
AM654 SoC has two Cadence OSPI controller instances under Flash
subsystem (FSS). Add DT nodes for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add USB0 as otg port and USB1 as host port.
Although USB0 can be used at super-speed, limit the
speed to high-speed for now till SERDES PHY support
is added.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
J721e has 2 USB super-speed controllers add them.
The USB2 PHY doesn't need any configuration.
USB3 PHY needs to be implemented using the Cadence
Sierra PHY. This support will be added later.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
MMC0_SDWP is not connected to the card. Indicate this by adding a
disable-wp flag.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
sdhci0 is connected to an eMMC and sdhci1 is connected to an SD card
slot. Add support for these nodes.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add nodes for the 3 SDHCI instances present on TI's J721E device.
instance 0 supports HS400 (8 bit bus widht, DDR, 400 MBps)
while instances 1 and 2 support SDR104 (4 bit width, SDR, 100 MBps) as
their highest speed modes. Currently, only High speed (50 MHz clock) has
been enabled.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the sub-mailbox nodes that are used to communicate between MPU and
various remote processors present in the J721E SoCs to the J721E common
processor 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 so are 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.
NOTE:
The GIC_SPI interrupts to be used are dynamically allocated and managed
by the System Firmware through the ti-sci-intr irqchip driver. So, only
valid interrupts (each cluster's User 0 IRQ output) that are used by the
sub-mailbox devices are enabled. This is done to minimize the number of
NavSS Interrupt Router outputs utilized.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The J721E Main NavSS block contains a Mailbox IP instance with
multiple clusters. Each cluster is equivalent to an Mailbox IP
instance on OMAP platforms.
Add all the Mailbox clusters as their own nodes under the MAIN
NavSS cbass_main_navss interconnect node instead of creating an
almost empty parent node for the new K3 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.
NOTE:
The NavSS only has a limited number of interrupts, so none of the
interrupts generated by a Mailbox IP are added by default. Only
the needed interrupts that are targeted towards the A72 GIC will
have to be added later on in the board dts files alongside the
corresponding sub-mailbox child nodes.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the sub-mailbox nodes that are used to communicate between MPU and
the two R5F remote processors present in the MCU domain to the AM654
EVM base board. These sub-mailbox nodes utilize the System Mailbox
clusters 0 and 1. The interrupts associated with the Mailbox Cluster
User interrupt used by the sub-mailbox nodes are also added. The GIC_SPI
interrupt to be used is dynamically allocated and managed by the System
Firmware through the ti-sci-intr irqchip driver. All the remaining
mailbox clusters are currently not used on A53 core, and so are disabled.
The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. The Cortex R5F processor
sub-system is 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 from cluster 0
is used in case of Lockstep mode.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The AM65x Main NavSS block contains a Mailbox IP instance with
multiple clusters. Each cluster is equivalent to an Mailbox IP
instance on OMAP platforms.
Add all the Mailbox clusters as their own nodes under the MAIN
NavSS cbass_main_navss interconnect node instead of creating an
almost empty parent node for the new K3 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.
NOTE:
The NavSS only has a limited number of interrupts, so none of the
interrupts generated by a Mailbox IP are added by default. Only
the needed interrupts that are targeted towards the A53 GIC will
have to be added later on in the board dts files alongside the
corresponding sub-mailbox child nodes.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The gic-its node unit-address has an additional zero compared
to the actual reg value. Fix it.
Fixes: 2d87061e70 ("arm64: dts: ti: Add Support for J721E SoC")
Reported-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The gic-its node unit-address has an additional zero compared
to the actual reg value. Fix it.
Fixes: ea47eed33a ("arm64: dts: ti: Add Support for AM654 SoC")
Reported-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The Main NavSS block on J721E SoCs contains a HwSpinlock IP instance that
is same as the IP on AM65x SoCs and similar to the IP on some OMAP SoCs.
Add the DT node for this on J721E SoCs. The node is present within the
Main NavSS block, and is added as a child node under the cbass_main_navss
interconnect node.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The Main NavSS block on AM65x SoCs contains a HwSpinlock IP instance
that is similar to the IP on some OMAP SoCs. Add the DT node for this
on AM65x SoCs. The node is present within the NavSS block, and is
added as a child node under the cbass_main_navss interconnect node.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Common processor board for K3 J721E platform has two push buttons
namely SW10 and SW11.
Add a gpio-keys device node to model them as input keys in Linux.
Add required pinmux nodes to set GPIO pins as input.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
There are 10 gpio instances inside SoC with 3 groups as below:
- Group1: main_gpio0, main_gpio2, main_gpio4, main_gpio6
- Group2: main_gpio1, main_gpio3, main_gpio5, main_gpio7
- Group3: wkup_gpio0, wkup_gpio1
Only one instance can be used in each group at a time. So use main_gpio0,
main_gpio1 and wkup_gpio0 for the current linux context and mark other
gpio nodes as disabled.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Similar to the gpio groups in main domain, there is one gpio group
in wakup domain with 2 module instances in it. This gpio group pins
out 84 lines(6 banks). Add DT node for these 2 gpio module instances.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
There are 8 instances of gpio modules in main domain divided into 2 groups:
- Group1: gpio0, gpio2, gpio4, gpio6
- Group2: gpio1, gpio3, gpio5, gpio7
Groups are created to provide protection between two different processor
virtual worlds. There are x gpio lines coming out of each group. Each module
in a group has equal x gpio lines pinned out. There is a top level mux for
selecting the module instance for each pin coming out of group. Exactly
one module can be selected to control the corresponding pin. This muxing
can be controlled along the pad mux configuration registers.
Group1 pins out 128 lines(8 banks). Group 2 pins out 36 lines(2 banks).
Add DT nodes for each module instance in the main domain. Users should
make sure that correct gpio instance is selected in their pad configuration.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Update the power-domain cells to 2 and mark all devices as
exclusive. Main uart 0 is the debug console for processor boards
and it is used by different software entities like u-boot, atf,
linux simultaneously. So just mark main_uart0 as shared device
for common processor board.
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Update the power-domain cells to 2 and mark all devices as
exclusive. Main uart 0 is the debug console for based boards
and it is used by different software entities like u-boot, atf,
linux. So just mark main_uart0 as shared device for base board.
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the on-chip SRAM present within the MCU domain as a mmio-sram node.
The K3 J721E SoCs have 1 MB of such memory. Any specific memory range
within this RAM needed by a driver/software module ought to be reserved
using an appropriate child node.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Wakeup domain in J721E SoC has an interrupt router connected to gpio
in wakeup domain. Add DT node for this interrupt router.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Main domain in J721E has the following interrupt controller instances:
- Main Domain GPIO Interrupt router connected to gpio in main domain.
- Under the Main Domain Navigator Subsystem(NAVSS)
- Main Navss Interrupt Router connected to main navss inta and mailboxes.
- Main Navss Interrupt Aggregator connected to main domain UDMASS
Add DT nodes for the interrupt controllers available in main domain.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the Interrupt controller node for the Interrupt Router present within
the Main NavSS module. This Interrupt Router can route 192 interrupts to
the GIC_SPI in 3 sets of 64 interrupts each. Note that the last set is
reserved for the host ID A72_3 for hypervisor usecases, so the node is
added only with 2 sets for the Linux kernel context (host id A72_2). This
is specified through the ti,sci-rm-range-girq property.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add Support for J721E Common Processor board support.
The EVM architecture 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 has most of the actual
connectors, power supply etc. A SOM (System on Module) is plugged on
to the common processor board and this contains the SoC, PMIC, DDR and
basic high speed components necessary for functionality. Add-n card
options add further functionality (such as additional Audio, Display,
networking options).
Note:
A) The minimum configuration required to boot up the board is System On
Module(SOM) + Common Processor Board.
B) Since there is just a single SOM and Common Processor Board, we are
maintaining common processor board as the base dts and SOM as the dtsi
that we include. In the future as more SOM's appear, we should move
common processor board as a dtsi and include configurations as dts.
C) All daughter cards beyond the basic boards shall be maintained as
overlays.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The J721E SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable lower system costs
of automotive applications such as infotainment, cluster, premium
Audio, Gateway, industrial and a range of broad market applications.
This SoC is designed around reducing the system cost by eliminating
the need of an external system MCU and is targeted towards ASIL-B/C
certification/requirements in addition to allowing complex software
and system use-cases.
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, Two C66x floating point DSPs.
* 3D GPU PowerVR Rogue 8XE GE8430
* Vision Processing Accelerator (VPAC) with image signal processor and Depth
and Motion Processing Accelerator (DMPAC)
* Two Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Two CSI2.0 4L RX plus one CSI2.0 4L TX, one eDP/DP, One DSI Tx, and
up to two DPI interfaces.
* Integrated Ethernet switch supporting up to a total of 8 external ports in
addition to legacy Ethernet switch of up to 2 ports.
* System MMU (SMMU) Version 3.0 and advanced virtualisation
capabilities.
* Upto 4 PCIe-GEN3 controllers, 2 USB3.0 Dual-role device subsystems,
16 MCANs, 12 McASP, eMMC and SD, UFS, OSPI/HyperBus memory controller, QSPI,
I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
* Two hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
management.
* Configurable L3 Cache and IO-coherent architecture with high data throughput
capable distributed DMA architecture under NAVSS
* Centralized System Controller for Security, Power, and Resource
Management (DMSC)
See J721E Technical Reference Manual (SPRUIL1, May 2019)
for further details: http://www.ti.com/lit/pdf/spruil1
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
AM654 base board does not have any PCIe slots. Disable all the
SERDES and PCIe instances.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add mux-controller DT node as a child node of scm_conf. This is
required for muxing SERDES between USB, PCIe and ICSS2 SGMII.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
GIC_ITS used in AM654 platform has the same configuration as that of
GIC_ITS used in Socionext SoCs. Add "socionext,synquacer-pre-its"
property to get PCI MSI working.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the MSCM RAM address space to the ranges property of the cbass_main
interconnect node so that the addresses can be translated properly.
This fixes the probe failure in the sram driver for the MSMC RAM node.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the address spaces for the R5F cores in MCU domain to the ranges
property of the cbass_mcu interconnect node so that the addresses
within the R5F nodes can be translated properly by the relevant OF
address API.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the on-chip SRAM present within the MCU domain as a mmio-sram node.
The K3 AM65x SoCs have 512 KB of such memory. Any specific memory range
within this RAM needed by a software module ought to be reserved using
an appropriate child node.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the address space for the MCU SRAM memory to the ranges property
of the cbass_mcu interconnect node so that the addresses within the
mcu_sram nodes and its children can be translated properly by the
relevant OF address API.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
There are 2 push buttons: SW5 and SW6 that are basically connected to
WKUP_GPIO0_24 and WKUP_GPIO0_27 respectively. Add the respective
nodes and the pinctrl data to set the mode to GPIO and Input.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add gpio0/1 nodes under main domain. They have 96 and 90 gpios
respectively and all are capable of generating banked interrupts.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add gpio0 node under wakeup domain. This has 56 gpios
and all are capable of generating banked interrupts.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Wakeup domain in AM654 SoC has an interrupt router connected to gpio
in wakeup domain. Add DT node for this interrupt router.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Main domain in AM654 has the following interrupt controller instances:
- Main Domain GPIO Interrupt router connected to gpio in main domain.
- Under the Main Domain Navigator Subsystem(NAVSS)
- Main Navss Interrupt Router connected to main navss inta and mailboxes.
- Main Navss Interrupt Aggregator connected to main domain UDMASS
Add DT nodes for the above three interrupt controllers available
in main domain.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Use the am654 specific compatible for dmsc. This allows to use
the am654 specific RM mapping table.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Contains a few DT updates on top of part 1 of the pull:
- MSMC RAM support (on-chip SRAM)
- Main system control module support
- USB support
- ADC support
There is an extra dt-binding update included, which has been acked
by Rob.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEtQ6szHmfiBT7fujkyvq9MXlQGhEFAlxme1MQHHQta3Jpc3Rv
QHRpLmNvbQAKCRDK+r0xeVAaESgdD/9aZCR4YX27oQV5YmIsT0DkleOve48MIK9A
ex2Qk5dtZM8GRPTKQPfI1i8kHMya9Hlwb3NRAjCrZnnNRjge5LvTcDWbvSeUzlc1
BjyygctF2Sb9zKKyCoqV9UklpXisqw3QTxwmtUkdHNAzeyiQe71MM8XCEeBHcjUu
7EZJUzBPX4fABo560/1phubG4PrLA7eNG8gPl0p0LFf91ug5c+QO0jv+3p7K9pvn
o4TxyKgEXwADfx4px6y6u4uEuO3OXtYWNGbRhAaGXUAgEFiOYz5gJlgti7M16kXb
D1YeE4oKl3aXbCjb2V5FzoNw08zgQZgRT3QltyQnAZ/kYs1CFX4ooXUMx9GuCaJ3
T2UZ33t2lm4zVoYhlpKlZlZlk7bO4U9ZaOeSv+daKitpxvZPyJM7NLRTawCc3yyZ
08RJmYAf9Rl6MmNbrhyX3XQ5VC9/O26L1Gx+92bRFvdNL3Uwoi6T8bWFxbWrdr76
cL2aF9rYzVq3dQetNiqozg0GB/sCgEO1luGgkfIMLS9CpNxLPNa6orysRfMfkdJh
b1R51dUq80cl5v2lagTquFKb1T+/GRgEv/hi9aIR/Yfl2ASufFFQGkCKUPyFnPoX
BhH7Izg47x8HwAPU2s20nMJmaZ7hJ0PW1MUqidXgIdto9X82QWLcUCoeGXG1PAJR
uWFlyqaNag==
=L6dq
-----END PGP SIGNATURE-----
Merge tag 'am654-for-v5.1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux into HEAD
AM654x SoC updates for v5.1 (part 2)
Contains a few DT updates on top of part 1 of the pull:
- MSMC RAM support (on-chip SRAM)
- Main system control module support
- USB support
- ADC support
There is an extra dt-binding update included, which has been acked
by Rob.
* tag 'am654-for-v5.1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux:
arm64: dts: ti: k3-am65-mcu: Add ADC nodes
dt-bindings: input: ti-tsc-adc: Add new compatible for AM654 SoCs
arm64: dts: ti: k3-am654-base-board: enable USB1
arm64: dts: ti: k3-am6: add USB support
arm64: dts: ti: am654: Add Main System Control Module node
arm64: dts: ti: k3-am65: Add MSMC RAM node
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
TI AM654 SoC has two ADC instances in the MCU domain. Add DT nodes for
the same.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Adds support for USB0 and USB1 instances on the AM6 SoC.
USB0 is limited to high-speed for now.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Main System control module support is added to the device tree to allow
driver to access to their control module registers.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The AM65 SoC has 2MB MSMC RAM. Add this as a mmio-sram
node so drivers can use it via genpool API.
Following areas are marked reserved:
- Lower 128KB for ATF
- 64KB@0xf0000 for SYSFW
- Upper 1MB for cache
The reserved locations are subject to change at runtime by
the bootloader.
Cc: Nishanth Menon <nm@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
On the am654x-evm, sdhci0 node is connected to an eMMC. Add node and
pinmux for the same.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add support for the Secure Digital Host Controller Interface (SDHCI)
present on TI's AM654 SOCs. It is compatible with eMMC5.1 Host
Specifications.
Enable only upto HS200 speed mode.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The 'arm,armv8' compatible string is only for software models. It adds
little value otherwise and is inconsistently used as a fallback on some
platforms. Remove it from those platforms.
This fixes warnings generated by the DT schema.
Reported-by: Michal Simek <michal.simek@xilinx.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
Acked-by: Nishanth Menon <nm@ti.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: Chanho Min <chanho.min@lge.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Wei Xu <xuwei5@hisilicon.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
Acked-by: Robert Richter <rrichter@cavium.com>
Acked-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Enable McSPI0 of main domain and add DT node for the SPI NOR flash
connected to CS0.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
There are 3 instances of McSPI in MCU domain and 4 instances in Main domain.
Add DT nodes for all McSPI instances present on AM654 SoC.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Populate power-domain property for UART nodes, this is required for
Linux to enable UART clocks via PM calls. Without this UART instances
not initialized by bootloader (like main_uart1) fails to work in Linux.
Also, drop current-speed property from main_uart1 and main_uart2 nodes
as these UARTs are not initialized before Linux boots up and current
speed is unknown.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add pinmux for main uart0 that is serves as console on AM654 EVM
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add pinctrl regions for the main and wkup mmr.
The range for main pinctrl region contains a gap
at offset 0x2e4, and because of this, the pinctrl
range is split into two sections.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
cbass_wakeup interconnect which is the parent of wakeup_uart node
defines address-cells=1 and size-cells=1, therefore fix up reg property
of wakeup_uart node accordingly. Otherwise, this UART instance fails to
probe if enabled.
Fixes: 4201af2544 ("arm64: dts: ti: am654: Add uart nodes")
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add TISCI compatible System controller for AM6 SoCs.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add secure proxy instance for Main domain
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add uart nodes for AM654 device tree components.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
AM65 has two PCIe controllers and each PCIe controller has '2' address
spaces one within the 4GB address space of the SoC and the other above
the 4GB address space of the SoC (cbass_main) in addition to the
register space. The size of the address space above the 4GB SoC address
space is 4GB. These address ranges will be used by CPU/DMA to access
the PCIe address space. In order to represent the address space above
the 4GB SoC address space and to represent the size of this address
space as 4GB, change address-cells and size-cells of interconnect to 2.
Since OSPI has similar need in MCU Domain Memory Map, change
address-cells and size-cells of cbass_mcu interconnect also to 2.
Fixes: ea47eed33a ("arm64: dts: ti: Add Support for AM654 SoC")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Vignesh R <vigneshr@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The EValuation Module(EVM) platform for AM654 consists of a
common Base board + one or more of daughter cards, which include:
a) "Personality Modules", which can be specific to a profile, such as
ICSSG enabled or Multi-media (including audio).
b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
c) Camera daughter card
d) various display panels
Among other options. There are two basic configurations defined which
include an "EVM" configuration and "IDK" (Industrial development kit)
which differ in the specific combination of daughter cards that are
used.
To simplify support, we choose to support just the base board as the
core device tree file and all daughter cards would be expected to be
device tree overlays.
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subsystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
NOTE:
1. AM654 is the first of the device variants, hence we introduce a
generic am65.dtsi.
2. We indicate the proper bus topology, the ranges are elaborated in
each bus segment instead of using the top level ranges to make sure
that peripherals in each segment use the address space accurately.
3. Peripherals in each bus segment is maintained in a separate dtsi
allowing for reuse in different bus segment representation from a
different core such as R5. This is also the reason for maintaining a
1-1 address map in the ranges.
4. Cache descriptions follow the ARM64 standard description.
Further tweaks may be necessary as we introduce more complex devices,
but can be introduced in context of the device introduction.
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
