UART nodes defined in the top-level AM64x SoC dtsi files are incomplete
and will not be functional unless they are extended with pinmux
information.
As the pinmux is only known at the board integration level, these
nodes should only be enabled when provided with this information.
Disable the UART nodes in the dtsi files and only enable the ones that
are actually pinned out on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20221017192532.23825-2-afd@ti.com
Range size of 0x2b4 was incorrect since there isn't 173 configurable
pins for muxing. Additionally there is a non-addressable region in the
mapping which requires splitting into two ranges.
main_pmx0 -> 67 pins
main_pmx1 -> 3 pins
Fixes: d361ed8845 ("arm64: dts: ti: Add support for J7200 SoC")
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20220919205723.8342-1-mranostay@ti.com
AM62A StarterKit (SK) board is a low cost, small form factor board
designed for TI’s AM62A7 SoC. It supports the following interfaces:
* 2 GB LPDDR4 RAM
* x1 Gigabit Ethernet interface
* x1 HDMI Port with audio
* x1 Headphone Jack
* x1 USB2.0 Hub with two Type A host and x1 USB Type-C DRP Port
* x1 UHS-1 capable µSD card slot
* M.2 SDIO Wifi + UART slot
* 1Gb OSPI NAND flash
* x4 UART through UART-USB bridge
* XDS110 for onboard JTAG debug using USB
* Temperature sensors, user push buttons and LEDs
* 40-pin User Expansion Connector
* 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO)
* 20-pin header for Programmable Realtime Unit (PRU) IO pins
* 40-pin CSI header
Add basic support for AM62A7-SK.
Schematics: https://www.ti.com/lit/zip/sprr459
Co-developed-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Devarsh Thakkar <devarsht@ti.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220901141328.899100-6-vigneshr@ti.com
The AM62A SoC belongs to the K3 Multicore SoC architecture platform that
can run edge AI applications with Video/Vision processing. This provides
advanced system integration with high security support to enable a broad
set of applications in industrial/automotive markets such as, driver
monitoring, machine vision, smart camera, eMirror, front camera,
robotics, and building automation.
Some highlights of AM62A SoC are:
* Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster. Dual/Single
core variants are provided in the same package to allow HW compatible
designs.
* One Device manager Cortex-R5F for system power and resource management, and
one Cortex-R5F for Functional Safety or general-purpose usage.
* One AI accelerator (up to 2 TOPS), using one C7x256V DSP w/Matrix Multiplier
accelerator (MMA) for Deep Learning usage.
* VPAC3L(Vision Pre-processing Accelerator), providing 12-bit ISP up to
315MPixel/s RGB+IR support, and Noise Filter for improved integrated imaging
and vision image processing.
* H.264/H.265 Video Encode/Decode. + Motion JPEG encode
* Display support, providing 24-bit RBG parallel interface up to 200MHz pixel
clock support for 2K display resolution.
* Integrated Giga-bit Ethernet switch supporting up to a total of two external
ports (TSN capable).
* 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for NAND/FPGA
connection, OSPI memory controller, 3x McASP for audio, 1x CSI-RX-4L for
Camera, eCAP/eQEP, ePWM, among other peripherals.
* Dedicated Centralized Hardware Security Module with support for secure boot,
debug security and crypto acceleration and trusted execution environment
* One 32 bit DDR Subsystem that supports LPDDR4, DDR4 memory types.
* Multiple low power modes support, ex: Deep sleep, Standby, MCU-only, enabling
battery powered system design.
More details about the SoCs can be found in the Technical Reference Manual:
https://www.ti.com/lit/zip/spruj16
Co-developed-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20220901141328.899100-5-vigneshr@ti.com
Add the compatible DT nodes for all EPWM instances
present in AM62 SoC. There is a total of 3 EPWM modules
available, sharing the same K3 IP as in AM64 SoC.
This also adds a required "ti,am62-epwm-tbclk" clock
provider node for the EPWM time-base clock.
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20220531205229.198011-2-g-vlaev@ti.com
AM642 SK has 8 leds connected to tpic2810 onboard. Add support for these
gpio leds.
Signed-off-by: Aparna M <a-m1@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220830123254.522222-1-vigneshr@ti.com
J7200 has an instance of SA2UL in the MCU domain.
Add DT node for the same.
The device is marked TI_SCI_PD_SHARED as parts of this IP are also
shared with the security co-processor and OP-TEE.
The RNG node is added but marked disabled as it is firewalled off for
exclusive use by OP-TEE. Any access to this device from Linux will
result in firewall errors. We add the node for completeness of the
hardware description.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20220823001136.10944-4-afd@ti.com
The SA2UL hardware is also used by SYSFW and OP-TEE. It should be
requested using the shared TI-SCI flags instead of the exclusive
flags or the request will fail.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20220823001136.10944-3-afd@ti.com
The first TX and first two RX PSI-L threads for SA2UL are used
by SYSFW on High Security(HS) devices. Use the next available
threads to prevent resource allocation conflicts.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20220823001136.10944-2-afd@ti.com
The hardware random number generator is used by OP-TEE and is access is
denied to other users with SoC level bus firewalls. Any access to this
device from Linux will result in firewall errors.
We could remove this node, but it is still valid device description,
and it is possible it could be re-enabled in the bootloader if OP-TEE
is not used. So only disable this node for now.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20220823001136.10944-1-afd@ti.com
The ELM module is used for GPMC NAND accesses for detecting
and correcting errors during reads due to NAND bitflips errors.
4-, 8-, and 16-bit error-correction levels are supported using
the BCH (Bose-ChaudhurI-Hocquenghem) algorithm.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220802104456.11069-3-rogerq@kernel.org
Add the node for SA2UL.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[s-anna@ti.com: drop label, minor cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>
[j-choudhary@ti.com: disable rng-node, change flag to shared]
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
Link: https://lore.kernel.org/r/20220711085743.10128-3-j-choudhary@ti.com
Add the address space for the SA2UL in MAIN domain to the ranges property
of the cbass_main interconnect node so that the addresses within the
corresponding 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: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
Link: https://lore.kernel.org/r/20220711085743.10128-2-j-choudhary@ti.com
Fix whitespace coding style: use single space instead of tabs or
multiple spaces around '=' sign in property assignment. No functional
changes (same DTB).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220526204139.831895-1-krzysztof.kozlowski@linaro.org
GICD region was overlapping with GICR causing the latter to not map
successfully, and in turn the gic-v3 driver would fail to initialize.
This issue was hidden till commit 2b2cd74a06 ("irqchip/gic-v3: Claim
iomem resources") replaced of_iomap() calls with of_io_request_and_map()
that internally called request_mem_region().
Respective console output before this patchset:
[ 0.000000] GICv3: /bus@100000/interrupt-controller@1800000: couldn't map region 0
Fixes: b8545f9d3a ("arm64: dts: ti: Add initial support for J721S2 SoC")
Cc: linux-stable@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220617151304.446607-1-mranostay@ti.com
Add node for dvi bridge and the endpoint nodes to
describe connection from
DSS => TI TFP410 DPI-to-DVI Bridge => HDMI connector.
Also add the required pinmux for HDMI hotplug and
powerdown
Signed-off-by: Rahul T R <r-ravikumar@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Link: https://lore.kernel.org/r/20220505090709.9252-3-r-ravikumar@ti.com
Add the endpoint nodes to describe connection from
DSS => MHDP => DisplayPort connector.
Also add the required pinmux nodes for hotplug.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Link: https://lore.kernel.org/r/20220429112639.13004-3-r-ravikumar@ti.com
Add DT nodes for DisplayPort and DisplayPort PHY. The DP is Cadence MHDP
8546 and the PHY is a Cadence Torrent PHY with TI WIZ wrapper.
Also add the required phy link nodes in the board dts files.
A slight irregularity in the bindings is the DPTX PHY register block,
which is in the MHDP IP, but is needed and mapped by the PHY.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Link: https://lore.kernel.org/r/20220429112639.13004-2-r-ravikumar@ti.com
Add the address space for SA3UL to the ranges property of the
cbass_main node.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220412075008.10553-1-j-choudhary@ti.com
AM62 SoC has one instance of MCAN in main domain. However, its
corresponding CAN signals are not brought out through a transceiver, on the
SK board. Therefore, add the device tree node in the main dt file and set
the status to disabled in the SK board dts file.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220418115802.5672-1-a-govindraju@ti.com
AM62 has 3 ECAP instances with 1 APWM each. Add DT nodes for the same.
Keep them disabled in am625-sk dts as these pins can be repurposed in
user exp connector.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20220419062902.196526-1-vigneshr@ti.com
Add nodes for I2C IO expander, OSPI Flash, Eth PHYs, SD and eMMC that
are present on AM625 SK board.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220427072954.8821-3-vigneshr@ti.com
WL1837 module is connected to SDHCI0 in AM642 SK. Enable it here.
This will enable the WiFi functionaliy on the board.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Aparna M <a-m1@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220414133612.13365-1-a-m1@ti.com
We found that (at least some versions of) the sci-fw set the base clock
rate for UARTs in the MCU domain to 96 MHz instead of the expected 48 MHz,
leading to incorrect baud rates when used from Linux.
As the 8250_omap driver will query the actual clock rate from the clk
driver when clock-frequency is unset, removing the incorrect property is
sufficient to fix the baud rate.
Fixes: 8abae9389b ("arm64: dts: ti: Add support for AM642 SoC")
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20220419075157.189347-1-matthias.schiffer@ew.tq-group.com
AM62 StarterKit (SK) board is a low cost, small form factor board
designed for TI’s AM625 SoC. It supports the following interfaces:
* 2 GB DDR4 RAM
* x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode
* x1 HDMI Port with audio + x1 OLDI/LVDS Display interface for Dual Display
* x1 Headphone Jack
* x1 USB2.0 Hub with two Type A host and x1 USB Type-C DRP Port
* x1 UHS-1 capable µSD card slot
* 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837
* 512 Mbit OSPI flash
* x4 UART through UART-USB bridge
* XDS110 for onboard JTAG debug using USB
* Temperature sensors, user push buttons and LEDs
* 40-pin User Expansion Connector
* 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO)
* 20-pin header for Programmable Realtime Unit (PRU) IO pins
* 15-pin CSI header
Add basic support for AM62-SK.
Schematics: https://www.ti.com/lit/zip/sprr448
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220225120239.1303821-6-vigneshr@ti.com
This add bare minimum DT for AM62 describing ARM compute clusters, Main,
MCU and Wakeup domain and interconnects, UARTs and I2Cs to enable
booting using ramdisk.
Hierarchy of dts files:
am62.dtsi:
base SoC skeleton which is common across am62xx family of SoCs,
includes am62-main.dtsi, am62-mcu.dtsi and am62-wakeup.dtsi
representing 3 domains and peripherals in each of these domain
am625.dtsi:
describes CPU cluster (Quad A53s). Since, am625 is a current superset
device with all peripherals, am625.dtsi includes am62.dtsi completing
SoC definition.
Individual EVMs using this SoC will just need to include am625.dtsi
thus making things easier for Board and SOM Vendors.
Future derivative SoCs will have their own am62{1-9}{1-9}.dtsi
overriding cluster / peripheral definitions with their own compatibles.
More details about the SoCs can be found in the Technical Reference Manual:
https://www.ti.com/lit/pdf/spruiv7
Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Co-developed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220225120239.1303821-5-vigneshr@ti.com
Specifying partitions directly under the flash nodes is deprecated. A
partitions node should used instead. The address and size cells are not
needed. Remove them.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Apurva Nandan<a-nandan@ti.com>
Link: https://lore.kernel.org/r/20220217181025.1815118-2-p.yadav@ti.com
The OSPI flash nodes are missing a space before the opening brace. Fix
that.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Apurva Nandan<a-nandan@ti.com>
Link: https://lore.kernel.org/r/20220217181025.1815118-1-p.yadav@ti.com
The interrupt-parent for wkup_gpioX instances are wrongly assigned as
main_gpio_intr instead of wkup_gpio_intr. Fix it.
Fixes: b8545f9d3a ("arm64: dts: ti: Add initial support for J721S2 SoC")
Signed-off-by: Keerthy <j-keerthy@ti.com>
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/20220203132647.11314-1-a-govindraju@ti.com
AM64x SoCs have two ESM modules, with one in MAIN voltage domain and the
other in MCU voltage domain. The error output from Main ESM module can
be routed to the MCU ESM module. The error output of MCU ESM can be
configured to reset the device. The MCU ESM configuration address space
is already opened and this patch opens the MAIN ESM configuration
address space.
For ESM details please refer technical reference manual at
https://www.ti.com/lit/pdf/spruim2
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Link: https://lore.kernel.org/r/20220210172246.27871-1-hnagalla@ti.com
Specifying partitions directly in the flash node is deprecated, a
fixed-partitions node should be used instead. Therefore, it doesn't
make sense to have these properties in the flash nodes.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: https://lore.kernel.org/r/20220203140240.973690-2-matthias.schiffer@ew.tq-group.com
Add the needed bus mappings for the two main RTI memory ranges and
the required device tree nodes in the main domain.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-By: Hari Nagalla <hnagalla@ti.com>
Link: https://lore.kernel.org/r/20220111134552.800704-1-christian.gmeiner@gmail.com
Signed-off-by: Nishanth Menon <nm@ti.com>
On J721s2 Linux console is on main_uart8 but to be consistent with other
J7 family of devices, alias it to ttyS2 (serial2). This also eliminates
need to have higher number of 8250 runtime UARTs.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20211223121650.26868-3-vigneshr@ti.com
Aliases are board specific and should be in board dts files.
So, move aliases to board dts and trim the list to interfaces that are
actually enabled.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20211223121650.26868-2-vigneshr@ti.com
The EVM architecture for J721S2 is similar to that of J721E and J7200. It
is as follows,
+------------------------------------------------------+
| +-------------------------------------------+ |
| | | |
| | Add-on Card 1 Options | |
| | | |
| +-------------------------------------------+ |
| |
| |
| +-------------------+ |
| | | |
| | SOM | |
| +--------------+ | | |
| | | | | |
| | Add-on | +-------------------+ |
| | Card 2 | | Power Supply
| | Options | | |
| | | | |
| +--------------+ | <---
+------------------------------------------------------+
Common Processor Board
Common Processor board is the baseboard that contains most of the actual
connectors, power supply etc. The System on Module (SoM) is plugged on to
the common processor baord. Therefore, add support for peripherals brought
out in the common processor board.
Common Processor Board: https://www.ti.com/tool/J721EXCPXEVM
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20211207080904.14324-6-a-govindraju@ti.com
A System on Module (SoM) contains the SoC, PMIC, DDR and basic high speed
components necessary for functionality. Therefore, add support for the
components present on the SoM.
SoM: https://www.ti.com/lit/zip/sprr439
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20211207080904.14324-5-a-govindraju@ti.com
The J721S2 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration in automotive ADAS applications and
industrial applications requiring AI at the network edge. This SoC extends
the Jacinto 7 family of SoCs with focus on lowering system costs and power
while providing interfaces, memory architecture and compute performance for
single and multi-sensor applications.
Some highlights of this SoC are:
* Dual Cortex-A72s in a single cluster, three clusters of lockstep capable
dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA), C7x
floating point Vector DSP.
* 3D GPU: Automotive grade IMG BXS-4-64
* Vision Processing Accelerator (VPAC) with image signal processor and
Depth and Motion Processing Accelerator (DMPAC)
* Two CSI2.0 4L RX plus one eDP/DP, two DSI Tx, and one DPI interface.
* Two Ethernet ports with RGMII support.
* Single 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems,
* Up to 20 MCANs, 5 McASP, eMMC and SD, OSPI/HyperBus memory controller,
QSPI, I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
* Hardware accelerator blocks containing AES/DES/SHA/MD5 called SA2UL
management.
* Chips and Media Wave521CL H.264/H.265 encode/decode engine
See J721S2 Technical Reference Manual (SPRUJ28 – NOVEMBER 2021)
for further details: http://www.ti.com/lit/pdf/spruj28
Introduce basic support for the J721S2 SoC.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20211207080904.14324-4-a-govindraju@ti.com
Disable mcasp nodes 0-2 because several required properties
are not present in the dtsi file as they are board specific.
These nodes can be enabled via an overlay whenever required.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: https://lore.kernel.org/r/20211117053806.10095-1-j-choudhary@ti.com
AM642 EVM has two CAN connecters brought out from the two MCAN instances in
the main domain through transceivers. Add device tree nodes for
transceivers and set the required properties in the mcan device tree nodes,
in EVM device tree file.
On AM642 SK there are no connectors brought out for CAN. Therefore, disable
the mcan device tree nodes in the SK device tree file.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20211122134159.29936-7-a-govindraju@ti.com
Add Support for two MCAN controllers present on the am64x SOC. Both support
classic CAN messages as well as CAN-FD.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20211122134159.29936-6-a-govindraju@ti.com
Add four MCAN nodes present on the common processor board and set a
maximum data rate of 5 Mbps. Disable all other nodes as they
are not brought out on the common processor board.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20211122134159.29936-5-a-govindraju@ti.com
Add support for 14 MCAN controllers in main domain and 2 MCAN controllers
present in mcu domain. All the MCAN controllers support classic CAN
messages as well as CAN_FD messages.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20211122134159.29936-4-a-govindraju@ti.com
AM654 base board and iot platforms do not have mcan instances pinned out.
Therefore, disable all the mcan instances.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20211122134159.29936-3-a-govindraju@ti.com
Add Support for two MCAN controllers present on the am65x SOC. Both support
classic CAN messages as well as CAN-FD.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20211122134159.29936-2-a-govindraju@ti.com
The Time Sync Event Router (TIMESYNC_INTRTR0) implements a set of
multiplexers to provide selection of active CPTS time sync events for
routing to CPTS capable modules.
This patch adds DT node TIMESYNC_INTRTR0 using "pinctrl-single" bindings.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20211202173114.9936-1-christian.gmeiner@gmail.com
Fix 'dtbs_check' in serdes_ln_ctrl (mux@4080) node by changing the node
name to mux-controller@4080.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20211126084555.17797-3-kishon@ti.com
Fix 'dtbs_check' in serdes_ln_ctrl (serdes-ln-ctrl@4080) node by
changing the node name to mux-controller@4080.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20211126084555.17797-2-kishon@ti.com
A72 Cluster has 48KB Icache, 32KB Dcache and 1MB L2 Cache
- ICache is 3-way set-associative
- Dcache is 2-way set-associative
- Line size are 64bytes
So correct the cache-sets info.
Fixes: 2d87061e70 ("arm64: dts: ti: Add Support for J721E SoC")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20211112063155.3485777-1-peng.fan@oss.nxp.com
Two carveout reserved memory nodes each have been added for each of the
other remote processors devices within the MAIN domain on the TI J721E
SK boards. These nodes are assigned to the respective rproc device nodes
as well. The first region will be used as the DMA pool for the rproc
devices, and the second region will furnish the static carveout regions
for the firmware memory.
An additional reserved memory node is also added to reserve a portion of
the DDR memory to be used for performing inter-processor communication
between all the remote processors running RTOS or baremetal firmwares.
8 MB of memory is reserved for this purpose, and this accounts for all
the vrings and vring buffers between all the possible pairs of remote
processors.
The current carveout addresses and sizes are defined statically for each
rproc device. The R5F processors do not have an MMU, and as such require
the exact memory used by the firmwares to be set-aside. The C71x DSP
processor does support a MMU called CMMU, but is not currently supported
and as such requires the exact memory used by the firmware to be
set-aside. The firmware images do not require any RSC_CARVEOUT entries
in their resource tables to allocate the memory for firmware memory
segments
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210929081333.26454-5-sinthu.raja@ti.com
Add the sub-mailbox nodes that are used to communicate between MPU and
various remote processors present in the J721E SoCs to the J721E EAIK
board. These include the R5F remote processors in the dual-R5F cluster
(MCU_R5FSS0) in the MCU domain and the two dual-R5F clusters
(MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; the two C66x DSP remote
processors and the single C71x DSP remote processor in the MAIN domain.
These sub-mailbox nodes utilize the System Mailbox clusters 0 through 4.
All the remaining mailbox clusters are currently not used on A72 core,
and are hence disabled.
The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. The R5F processor
sub-systems are assumed to be running in Split mode, so a sub-mailbox
node is used by each of the R5F cores. Only the sub-mailbox node for
the first R5F core in each cluster is used in case of a Lockstep mode
for that R5F cluster.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210929081333.26454-4-sinthu.raja@ti.com
J721E Starter Kit (SK)[1] is a low cost, small form factor board designed
for TI’s J721E SoC. TI’s J721E SoC comprises of dual core A72, high
performance vision accelerators, video codec accelerators, latest C71x
and C66x DSP, high bandwidth real-time IPs for capture and display, GPU,
dedicated safety island and security accelerators. The SoC is power
optimized to provide best in class performance for industrial and
automotive applications.
J721E SK supports the following interfaces:
* 4 GB LPDDR4 RAM
* x1 Gigabit Ethernet interface
* x1 USB 3.0 Type-C port
* x3 USB 3.0 Type-A ports
* x1 PCIe M.2 E Key
* x1 PCIe M.2 M Key
* 512 Mbit OSPI flash
* x2 CSI2 Camera interface (RPi and TI Camera connector)
* 40-pin Raspberry Pi GPIO header
Add basic support for J721E-SK.
[1] https://www.ti.com/tool/SK-TDA4VM
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210929081333.26454-3-sinthu.raja@ti.com
This adds the devices trees for IOT2050 Product Generation 2 (PG2)
boards. We have Basic and an Advanced variants again, differing in
number of cores, RAM size, availability of eMMC and further details.
The major difference to PG1 is the used silicon revision (SR2.x on
PG2).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/cc868da8264324bde2c87d0c01d4763e3678c706.1632657917.git.jan.kiszka@web.de
The current IOT2050 devices are Product Generation 1 (PG1), using SR1.0
AM65x silicon. Upcoming PG2 devices will use SR2.x SoCs and will
therefore need separate device trees. Prepare for that by factoring out
common bits that will be shared across both generations.
At this chance, drop a link to the product homepage to in the top-level
dts files. Also fix a typo in my email address in some headers.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/31fece05f9728a852c0632985c4fa537cced4ece.1632657917.git.jan.kiszka@web.de
Analogously to the am654-base-board, configure the mailboxes for the two
R5F cores, add them and the already existing memory carve-outs to the
related MCU nodes. Allows to load applications under Linux onto the
cores, e.g. the RTI watchdog firmware.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/1776f8be19b39a938d9248fcfc5332b753783c3e.1632657917.git.jan.kiszka@web.de
The IOT2050 devices described so far are using SR1.0 silicon, thus do
not have the additional PRUs of the ICSSG of the SR2.0. Disable them.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Aswath Govindraju <a-govindraju@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/189a91866fb1af02e4fd2345dc56774aa069d5ba.1632657917.git.jan.kiszka@web.de
This ensures that the SD card will remain mmc0 across Basic and Advanced
devices, also avoiding surprises for users coming from the downstream
kernels.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/fe20d6346f119a28e47d129b616682001299cf0e.1632657917.git.jan.kiszka@web.de
Add j7200-evm compatible to the board to allow the board to distinguish
itself from other platforms that may be added in the future.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210925201430.11678-5-nm@ti.com
Add j721e-evm compatible to the board to allow the board to distinguish
itself from other platforms that are pending to be added.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210925201430.11678-4-nm@ti.com
Make sure that the platforms are grouped together per SoC. This helps
keep the Makefile readable as newer platforms get added to the list.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210915121442.27112-1-nm@ti.com
Add the DT nodes for the ICSSG0 and ICSSG1 processor subsystems that are
present on the K3 AM64x SoCs. The two ICSSGs are identical to each other
for the most part, with some of the peripheral pins from ICSSG1 not pinned
out. Each ICSSG instance is represented by a PRUSS subsystem node and other
child nodes.
The nodes are all added and enabled in the common k3-am64-main.dtsi
file by default. The MDIO nodes need pinctrl lines, and so should be
enabled only on boards where they are actually wired and pinned out
for ICSSG Ethernet. Any new board dts file should disable these if
they are not sure. These are disabled in the existing AM64x board dts
files to begin with.
The ICSSGs on K3 AM64x SoCs are very similar to the versions of the ICSSG
on K3 J721E and AM65x SR2.0 SoCs. The IRAM and BroadSize RAM sizes are all
identical to those on J721E SoCs. All The ICSSG host interrupts intended
towards the main Arm core are also shared with other processors on the SoC,
and can be partitioned as per system integration needs.
The ICSSG subsystem node contains the entire address space. The various
sub-modules of the ICSSG are represented as individual child nodes (so
platform devices themselves) of the PRUSS subsystem node. These include:
- two Programmable Real-Time Units (PRUs)
- two auxiliary PRU cores called RTUs
- two Transmit Programmable Real-Time Units (Tx_PRUs)
- Interrupt controller (INTC)
- a 'memories' node containing all the ICSSG level Data RAMs
- Real Time Media Independent Interface controller (MII_RT)
- Gigabit capable MII_G_RT
- ICSSG CFG sub-module providing two internal clock muxes, with the
default clock parents also assigned using the assigned-clock-parents
property.
The default names for the firmware images for each PRU, RTU and Tx_PRU
cores are defined as follows using the 'firmware-name' property (these
can be adjusted either in derivative board dts files or through sysfs at
runtime if required):
ICSSG0 PRU0 Core : am64x-pru0_0-fw ; PRU1 Core : am64x-pru0_1-fw
ICSSG0 RTU0 Core : am64x-rtu0_0-fw ; RTU1 Core : am64x-rtu0_1-fw
ICSSG0 Tx_PRU0 Core : am64x-txpru0_0-fw ; Tx_PRU1 Core : am64x-txpru0_1-fw
ICSSG1 PRU0 Core : am64x-pru1_0-fw ; PRU1 Core : am64x-pru1_1-fw
ICSSG1 RTU0 Core : am64x-rtu1_0-fw ; RTU1 Core : am64x-rtu1_1-fw
ICSSG1 Tx_PRU0 Core : am64x-txpru1_0-fw ; Tx_PRU1 Core : am64x-txpru1_1-fw
Note:
1. The ICSSG INTC on AM64x SoCs share all the host interrupts with other
processors, so use the 'ti,irqs-reserved' property in derivative board
dts files _if_ any of them should not be handled by the host OS.
2. There are few more sub-modules like the Industrial Ethernet Peripherals
(IEPs), eCAP, PWM, UART that do not have bindings and so will be added
in the future.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210919202935.15604-1-s-anna@ti.com
When commit 64f9147d91 ("arm64: dts: ti: am654: Add thermal
zones") introduced thermal-zones for am654, it defined as under the
common am65-wakeup bus segment, when it is am654 specific (other SoC
spins can have slightly different thermal characteristics). Futher,
thermal-zones is introduced under simple-bus node, when it has no
actual register or base address.
So, move it to it's rightful place under am654 SoC dtsi under the base
node.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Link: https://lore.kernel.org/r/20210916181801.32588-1-nm@ti.com
Since probe order of mmc can vary depending on device tree dependencies,
Lets try and introduce a consistent definition of what mmc0, 1 are
across platforms.
NOTE: Certain platforms may choose to have overrides due to various
legacy reasons, we permit that in the board specific alias definition.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20210915135415.5706-1-nm@ti.com
*dtbs_check* on
"Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml" YAML file
resulted in the following errors.
pcie@5500000: ranges: 'oneOf' conditional failed, one must be fixed:
pcie@5600000: ranges: 'oneOf' conditional failed, one must be fixed
Cleanup "ranges" property in "pcie" DT node to fix the above errors.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210915055358.19997-7-kishon@ti.com
J7200 has 4 virtual functions for the first four physical function.
Add *max-virtual-functions* in pcie-ep DT node to represent the same.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210915055358.19997-6-kishon@ti.com
commit 3276d9f53c ("arm64: dts: ti: k3-j7200-main: Add PCIe device
tree node") incorrectly added PCIe bus numbers from 0 to 15 (copy-paste
from J721E node). Enable all the supported bus numbers from 0 to 255
defined in PCIe spec here.
Fixes: 3276d9f53c ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210915055358.19997-5-kishon@ti.com
commit 3276d9f53c ("arm64: dts: ti: k3-j7200-main: Add PCIe device
tree node") incorrectly added "vendor-id" and "device-id" as 16-bit
properties though both of them are 32-bit properties. Fix it here.
Fixes: 3276d9f53c ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210915055358.19997-4-kishon@ti.com
commit 4e5833884f ("arm64: dts: ti: k3-j721e-main: Add PCIe device
tree nodes") restricted PCIe bus numbers from 0 to 15 (due to SMMU
restriction in J721E). However since SMMU is not enabled, allow the full
supported bus numbers from 0 to 255.
Fixes: 4e5833884f ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210915055358.19997-3-kishon@ti.com
commit 4e5833884f ("arm64: dts: ti: k3-j721e-main: Add PCIe device
tree nodes") added "max-virtual-functions" to have 16 bit values.
Fix "max-virtual-functions" in PCIe endpoint (EP) nodes to have 8 bit
values instead of 16.
Fixes: 4e5833884f ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210915055358.19997-2-kishon@ti.com
ecap0 can be configured to use pad ECAP0_IN_APWM_OUT (D18) which has a
signal connected to Pin 1 of J3. Add support for adding this pinmux so
that pwm can be observed on pin 1 of Header J3
Also mark all un-used epwm and ecap pwm nodes as disabled.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20210721113625.17299-5-lokeshvutla@ti.com
ecap0 can be configured to use pad ECAP0_IN_APWM_OUT (D18) which has a
signal connected to Pin 1 of J12 on EVM. Add support for adding this
pinmux so that pwm can be observed on pin 1 of Header J12
Also mark all un-used epwm and ecap pwm nodes as disabled.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20210721113625.17299-4-lokeshvutla@ti.com
There are 3 instances of ecap modules that are capable of generating
a pwm when configured in apwm mode. Add DT nodes for these 3 ecap
instances.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20210721113625.17299-3-lokeshvutla@ti.com
Two carveout reserved memory nodes each have been added for each of the
R5F remote processor devices within the MAIN domain on the TI AM642 EVM
and SK boards. These nodes are assigned to the respective rproc device
nodes as well. The first region will be used as the DMA pool for the rproc
devices, and the second region will furnish the static carveout regions
for the firmware memory.
An additional reserved memory node is also added to reserve a portion of
the DDR memory to be used for performing inter-processor communication
between all the remote processors running RTOS or baremetal firmwares.
8 MB of memory is reserved for this purpose, and this accounts for all
the vrings and vring buffers between all the possible pairs of remote
processors.
The current carveout addresses and sizes are defined statically for each
rproc device. The R5F processors do not have an MMU, and as such require
the exact memory used by the firmwares to be set-aside. The firmware
images do not require any RSC_CARVEOUT entries in their resource tables
to allocate the memory for firmware memory segments.
NOTE:
1. The R5F1 carveouts are needed only if the R5F cluster is running in
Split (non Single-CPU) mode. The reserved memory nodes can be disabled
later on if there is no use-case defined to use the corresponding
remote processor.
2. The AM64x SoCs do not have any DSPs and one less R5F cluster compared
to J721E SoCs. So, while the carveout memories reserved for the R5F
clusters present on the SoC match to those on J721E, the overall
memory map reserved for firmwares is quite different. The number of
R5F clusters on AM64x SoCs are same as on J7200 SoCs, but the AM64x
SoCs also have an additional M4F core, so the RTOS IPC memory region
is 1 MB higher than on J7200 SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210615195718.15898-4-s-anna@ti.com
Add the required 'mboxes' property to all the R5F processors for the
TI AM642 EVM and SK boards. The mailboxes and some shared memory are
required for running the Remote Processor Messaging (RPMsg) stack
between the host processor and each of the R5Fs.
The chosen sub-mailboxes match the values used in the current firmware
images. This can be changed, if needed, as per the system integration
needs after making appropriate changes on the firmware side as well.
Note that any R5F Core1 resources are needed and used only when that
R5F cluster is configured for Split-mode.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210615195718.15898-3-s-anna@ti.com
The AM64x SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. Both the R5F clusters are present within the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a new "Single-CPU" mode
or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
The mode is restricted to "Single-CPU" on some devices with the
appropriate eFuse bit set, but the most common devices support both
modes. These subsystems have 64 KB each Tightly-Coupled Memory (TCM)
internal memories for each core split between two banks - ATCM and
BTCM (further interleaved into two banks). The TCMs of both Cores
are combined in Single-CPU mode to provide a larger 128 KB of memory.
The other notable difference is that the TCMs are spaced 1 MB apart
on these SoCs unlike the existing SoCs.
Add the DT nodes for both these MAIN domain R5F cluster/subsystems,
the two R5F cores are added as child nodes to each of the corresponding
R5F cluster node. Both the clusters are configured to run in Split mode
by default, with the ATCMs enabled to allow the R5 cores to execute
code from DDR with boot-strapping code from ATCM. The inter-processor
communication between the main A72 cores and these processors is
achieved through shared memory and Mailboxes.
The following firmware names are used by default for these cores, and
can be overridden in a board dts file if desired:
MAIN R5FSS0 Core0: am64-main-r5f0_0-fw (both in Single-CPU & Split modes)
MAIN R5FSS0 Core1: am64-main-r5f0_1-fw (needed only in Split mode)
MAIN R5FSS1 Core0: am64-main-r5f1_0-fw (both in Single-CPU & Split modes)
MAIN R5FSS1 Core1: am64-main-r5f1_1-fw (needed only in Split mode)
NOTE:
A R5FSS cluster can be configured in "Single-CPU" mode by using a
value of 2 for the "ti,cluster-mode" property. Value of 1 is not
permitted (fails the dtbs_check).
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210615195718.15898-2-s-anna@ti.com
Due to a limitation for USB DFU boot mode, SPL load address has to be less
than or equal to 0x70001000. So, load address of SPL and TF-A have been
moved to 0x70000000 and 0x701c0000 respectively, in U-Boot version 2021.10.
Therefore, update TF-A's location in the device tree node.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210616171224.24635-4-a-govindraju@ti.com
The final 128KB in SRAM is reserved by default for DMSC-lite code and
secure proxy communication buffer. The memory region used for DMSC-lite
code can be optionally freed up by secure firmware API[1]. However, the
buffer for secure proxy communication is not configurable. This default
hardware configuration is unique for AM64.
Therefore, indicate the area reserved for DMSC-lite code and secure proxy
communication buffer in the oc_sram device tree node.
[1] - http://downloads.ti.com/tisci/esd/latest/6_topic_user_guides/security_handover.html#triggering-security-handover
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210616171224.24635-3-a-govindraju@ti.com
8250_omap compatible UART IPs on all SoCs have registers aligned at 4
byte address boundary and constant byte addressability. Thus there is no
need for reg-io-width or reg-shift DT properties. These properties are
not used by 8250_omap driver nor documented as part of binding document.
Therefore drop them.
This is in preparation to move omap-serial.txt to YAML format.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210607134558.23704-1-vigneshr@ti.com
ti,pindir-d0-out-d1-in property is expected to be of type boolean.
Therefore, fix the property accordingly.
Fixes: 4fb6c04683 ("arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210608051414.14873-3-a-govindraju@ti.com
The current device tree CPSW3g node adds non-zero "mac-address" property to
the ports, which prevents random MAC address assignment to network devices
if bootloader failed to update DT. This may cause more then one host to
have the same MAC in the network.
mac-address = [00 00 de ad be ef];
mac-address = [00 01 de ad be ef];
In addition, there is one MAC address available in eFuse registers which
can be used for default port 1.
Hence, fix ports MAC properties by:
- resetting "mac-address" property to 0
- adding ti,syscon-efuse = <&main_conf 0x200> to Port 1
Fixes: 3753b12877 ("arm64: dts: ti: k3-am64-main: Add CPSW DT node")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210608184940.25934-1-grygorii.strashko@ti.com
AM642-SK has no PCIe slot. Disable it here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603142251.14563-6-kishon@ti.com
AM642 EVM has a x4 lane PCIe connector. Enable PCIe in RC mode here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603142251.14563-4-kishon@ti.com
AM64 has one PCIe instance which can be configured in either
host mode (RC) or device mode (EP). Add PCIe DT node for host
mode and device mode here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603142251.14563-3-kishon@ti.com
AM64 has one SERDES 10G instance. Add SERDES DT node for it.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603142251.14563-2-kishon@ti.com
Commit 66db854b1f ("arm64: dts: ti: k3-j721e-common-proc-board:
Configure the PCIe instances") and
commit 02c35dca2b ("arm64: dts: ti: k3-j721e: Enable Super-Speed
support for USB0") added PHY DT nodes with node name as "link"
However nodes with #phy-cells should be named 'phy' as discussed in [1].
Re-name subnodes of serdes in J721E to 'phy'.
[1] -> http://lore.kernel.org/r/20200909203631.GA3026331@bogus
Fixes: 66db854b1f ("arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances")
Fixes: 02c35dca2b ("arm64: dts: ti: k3-j721e: Enable Super-Speed support for USB0")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603143427.28735-5-kishon@ti.com
Use external clock for all the SERDES used by PCIe controller. This will
make the same clock used by the local SERDES as well as the clock
provided to the PCIe connector.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603143427.28735-4-kishon@ti.com
Add #clock-cells property to serdes DT node since the serdes is also now
modeled as a clock provider and include the input clocks "pll0_refclk"
and "pll1_refclk" which are parents to the clocks modeled by serdes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603143427.28735-3-kishon@ti.com
Rename the external refclk inputs to the SERDES from
dummy_cmn_refclk/dummy_cmn_refclk1 to cmn_refclk/cmn_refclk1
respectively. Also move the external refclk DT nodes outside the
cbass_main DT node. Since in j721e common processor board, only the
cmn_refclk1 is connected to 100MHz clock, fix the clock frequency.
Fixes: afd094ebe6 ("arm64: dts: ti: k3-j721e-main: Add WIZ and SERDES PHY nodes")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603143427.28735-2-kishon@ti.com
The ICSSGs on K3 J721E SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each ICSSG instance. The MDIO module
used within the ICSSG is similar to the MDIO Controller used
in TI Davinci SoCs. A bus frequency of 1 MHz is chosen for the
MDIO operations.
The nodes are added and enabled in the common k3-j721e-main.dtsi
file by default, and disabled in the existing J721E board dts
file. These nodes need pinctrl lines, and so should be enabled
only on boards where they are actually wired and pinned out for
ICSSG Ethernet. Any new board dts file should disable these if
they are not sure.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210601150032.11432-3-s-anna@ti.com
The ICSSGs on K3 AM65x SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each ICSSG instance. The MDIO module
used within the ICSSG is similar to the MDIO Controller used
in TI Davinci SoCs. A bus frequency of 1 MHz is chosen for the
MDIO operations.
The nodes are added and enabled in the common k3-am65-main.dtsi
file by default, and disabled in the existing AM65 board dts
files. These nodes need pinctrl lines, and so should be enabled
only on boards where they are actually wired and pinned out for
ICSSG Ethernet. Any new board dts file should disable these if
they are not sure.
Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: move the disabled status to board dts files]
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210601150032.11432-2-s-anna@ti.com
UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1].
Add support by removing the no-1-8-v tag and including the voltage
regulator device tree nodes for power cycling.
However, the 4 bit interface of AM65 SR 1.0 cannot be supported at 3.3 V or
1.8 V because of erratas i2025 and i2026 [2]. As the SD card is the primary
boot mode for development usecases, continue to enable SD card and disable
UHS-I modes in it to minimize any ageing issues happening because of
erratas.
k3-am6528-iot2050-basic and k3-am6548-iot2050-advanced boards use S.R. 1.0
version of AM65 SoC. Therefore, add no-1-8-v in sdhci1 device tree node of
the common iot2050 device tree file.
[1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1
[2] - https://www.ti.com/lit/er/sprz452e/sprz452e.pdf
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210529033749.6250-1-a-govindraju@ti.com
The MCU RGMII MCU_RGMII1_TXC pin is defined as input by mistake, although
this does not make any difference functionality wise it's better to update
to avoid confusion.
Hence fix MCU RGMII MCU_RGMII1_TXC pin pinmux definitions to be an output
in K3 am654x/j721e/j7200 board files.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210526132041.6104-1-grygorii.strashko@ti.com
Enable work around feature built into the controller to address issue with
RX Sensitivity for USB2 PHY.
Fixes: 6197d7139d ("arm64: dts: ti: k3-j7200-main: Add USB controller")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210512153308.5840-1-a-govindraju@ti.com
There are no sub-mailbox devices defined currently for both the
IOT2050 boards. These are usually dictated by the firmwares running
on the R5F remote processors and the applications they provide.
Defining the actual sub-mailboxes will also dictate the interrupts
the clusters will use for interrupts on the Cortex-A53 cores.
Disable all of the Mailbox clusters until the sub-mailboxes are
defined and used. This fixes the warnings around the missing
interrupts with the upcoming conversion of the OMAP Mailbox binding
to YAML format.
Signed-off-by: Suman Anna <s-anna@ti.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210514212016.3153-1-s-anna@ti.com
Interrupt routers are memory mapped peripherals, that are organized
in our dts bus hierarchy to closely represents the actual hardware
behavior.
However, without explicitly calling out the reg property, using
2021.03+ dt-schema package, this exposes the following problem with
dtbs_check:
/arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000:
interrupt-controller0: {'type': 'object'} is not allowed for
{'compatible': ['ti,sci-intr'], .....
Even though we don't use interrupt router directly via memory mapped
registers and have to use it via the system controller, the hardware
block is memory mapped, so describe the base address in device tree.
This is a valid, comprehensive description of hardware and permitted
by the existing ti,sci-intr schema.
Reviewed-by: Tero Kristo <kristo@kernel.org>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210511194821.13919-1-nm@ti.com
Instead of using empty ranges property, lets map explicitly the address
range that is mapped onto the dma / navigator subsystems (navss/dmss).
This is also exposed via the dtbs_check with dt-schema newer than
2021.03 version by throwing out following:
arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000: main-navss:
{'type': 'object'} is not allowed for
{'compatible': ['simple-mfd'], '#address-cells': [[2]], .....
This has already been correctly done for J7200, however was missed for
other k3 SoCs. Fix that oversight.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tero Kristo <kristo@kernel.org>
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210510145429.8752-1-nm@ti.com
Lets rename the node name of TI-SCI node to be system-controller as it
is a better standardized name for the function that TI-SCI plays in the
SoC.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tero Kristo <kristo@kernel.org>
Link: https://lore.kernel.org/r/20210510145033.7426-5-nm@ti.com
The DMSC node does'nt require any of "#address-cells", "#size-cells"
or "ranges" property as the child nodes are representations of SoC's
system controller itself, so align it with the bindings.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tero Kristo <kristo@kernel.org>
Link: https://lore.kernel.org/r/20210510145033.7426-4-nm@ti.com
We currently use clocks as the node name for the node representing
TI-SCI clock nodes. This is better renamed to being clock-controller
as that is a better representative of the system controller function
as a clock controller for the SoC.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tero Kristo <kristo@kernel.org>
Link: https://lore.kernel.org/r/20210510145033.7426-2-nm@ti.com
Traffic through main NAVSS interconnect is coherent wrt ARM caches on
J7200 SoC. Add missing dma-coherent property to main_navss node.
Also add dma-ranges to be consistent with mcu_navss node
and with AM65/J721e main_navss and mcu_navss nodes.
Fixes: d361ed8845 ("arm64: dts: ti: Add support for J7200 SoC")
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210510180601.19458-1-vigneshr@ti.com
AM654 EVM boards are not shipped with OV5640 sensor module, it is a
separate purchase. OV5640 module is also just one of the possible
sensors or capture boards you can connect.
However, for some reason, OV5640 has been added to the board dts file,
making it cumbersome to use other sensors.
Remove the OV5640 from the dts file so that it is easy to use other
sensors via DT overlays.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210423083120.73476-1-tomi.valkeinen@ideasonboard.com
The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210326130034.15231-4-p.yadav@ti.com
The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210326130034.15231-3-p.yadav@ti.com
The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210326130034.15231-2-p.yadav@ti.com
The following speed modes are now supported in J7200 SoC,
- HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
- UHS-I speed modes in MMCSD1 subsystem [1].
Add support for UHS-I modes by adding voltage regulator device tree nodes
and corresponding pinmux details, to power cycle and voltage switch cards.
Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
device tree nodes.
Also update the delay values for various speed modes supported, based on
the revised january 2021 J7200 datasheet[2].
[1] - section 12.3.6.1.1 MMCSD Features, in
https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
(SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
[2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
(SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20210326064120.31919-4-a-govindraju@ti.com
There are 6 gpio instances inside SoC with 2 groups as show below:
Group one: wkup_gpio0, wkup_gpio1
Group two: main_gpio0, main_gpio2, main_gpio4, main_gpio6
Only one instance from each group can be used at a time. So use main_gpio0
and wkup_gpio0 in current linux context and disable the rest of the nodes.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20210326064120.31919-3-a-govindraju@ti.com
There are 4 instances of gpio modules in main domain:
gpio0, gpio2, gpio4 and gpio6
Groups are created to provide protection between different processor
virtual worlds. Each of these modules I/O pins are muxed within the
group. Exactly one module can be selected to control the corresponding
pin by selecting it in the pad mux configuration registers.
This group in main domain pins out 69 lines (5 banks). Add DT modes for
each module instance in the main domain.
Similar to the gpio groups in main domain, there is one gpio group in
wakeup domain with 2 module instances in it.
The gpio group pins out 72 pins (6 banks) of the first 85 gpio lines. Add
DT nodes for each module instance in the wakeup domain.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20210326064120.31919-2-a-govindraju@ti.com
Add the sub-mailbox nodes that are used to communicate between MPU and
various remote processors present in the AM64x SoCs for the AM642 EVM
and AM642 SK boards. These include the R5F remote processors in the two
dual-R5F clusters (MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; and a
M4 processor in the MCU safety island.
These sub-mailbox nodes utilize the System Mailbox clusters 2, 4 and 6.
The remaining clusters 3, 5 and 7 are currently not used, and so are
disabled. Clusters 0 and 1 were never added to the dts file as they do
not support interrupts towards the A53 core.
The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. The R5F processor
sub-systems are assumed to be running in Split mode, so a sub-mailbox
node is used by each of the R5F cores. Only the sub-mailbox node for
the first R5F core in each cluster is used in case of a Single-CPU mode
for that R5F cluster.
NOTE:
The cluster nodes only have the Mailbox IP interrupt outputs that are
routed to the GIC_SPI. The sub-mailbox nodes' irq-id are indexing into
the listed interrupts, with the usr-id using the actual interrupt output
line number from the Mailbox IP.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Gowtham Tammana <g-tammana@ti.com>
Link: https://lore.kernel.org/r/20210322185430.957-4-s-anna@ti.com
The AM64 MAIN domain contains a Mailbox IP instance with multiple
clusters, and is a variant of the IP on current AM65x and J721E
SoCs. The AM64x SoC has only 8 clusters with no interrupts routed
to the A53 core on the first 2 clusters. The interrupt outputs
from the IP do not go through any Interrupt Routers and are
hard-wired to each processor, with only couple of interrupts
from each cluster reaching the A53 core.
Add all the Mailbox clusters that generate interrupts towards the
A53 core as their own nodes under the cbass_main node instead of
creating an almost empty parent node for the Mailbox IP and the
clusters as its child nodes. All these nodes are enabled by default
in the base dtsi file, but any cluster that does not define any
child sub-mailbox nodes should be disabled in the corresponding
board dts files.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Gowtham Tammana <g-tammana@ti.com>
Link: https://lore.kernel.org/r/20210322185430.957-3-s-anna@ti.com
The AM64x SoC contains a HwSpinlock IP instance that is a minor variant
of the IP on existing TI K3 SoCs such as AM65x, J721E or J7200 SoCs.
Add the DT node for this on AM64x SoCs. The node is present within the
MAIN domain, and is added as a child node under the cbass_main node.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Gowtham Tammana <g-tammana@ti.com>
Link: https://lore.kernel.org/r/20210322185430.957-2-s-anna@ti.com
The gpio0 subsystem present in MCU domain might be used by firmware and is
not pinned out in evm/sk. Therefore, reserve it for MCU firmware.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210319051950.17549-3-a-govindraju@ti.com
Add device tree nodes for GPIO modules and interrupt controller in main
and mcu domains.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210319051950.17549-2-a-govindraju@ti.com
Both AM64 EVM and SK have a 512Mb S28HS512T Octal SPI NOR flash.
Add DT node for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20210318113757.21012-2-vigneshr@ti.com
AM64 SoC has a single ADC IP with 8 channels. Add DT node for the same.
Default usecase is to control ADC from non Linux core on the system on
AM642 GP EVM, therefore mark the node as reserved in k3-am642-evm.dts
file. ADC lines are not pinned out on AM642 SK board, therefore disable
the node in k3-am642-sk.dts file.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210318113443.20036-1-vigneshr@ti.com
AM64 EVM board has a micro USB 2.0 AB connector and the USB0_VBUS is
connected with a resistor divider in between. USB0_DRVVBUS pin is muxed
between USB0_DRVVBUS and GPIO1_79 signals.
Add the corresponding properties and set the pinmux mode for USB subsystem
in the evm dts file.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Link: https://lore.kernel.org/r/20210317043007.18272-3-a-govindraju@ti.com
Add DT node for the single USB subsystem in main dtsi file.
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>
Acked-by: Roger Quadros <rogerq@ti.com>
Link: https://lore.kernel.org/r/20210317043007.18272-2-a-govindraju@ti.com
Add pinmux details and device tree node for the EEPROM attached to SPI0
module in main domain.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210309162315.22743-1-a-govindraju@ti.com
TI J7200 has the Cadence OSPI controller for interfacing with OSPI
flashes. Add its node to allow using SPI flashes.
Signed-off-by: Pratyush Yadav <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-4-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-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>
