AM64x device has 4 R5F cores in the main domain. TI MCU firmware uses
main domain timers as tick timers in these firmwares. Hence keep them
as reserved in the Linux device tree.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250502220325.3230653-12-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
There are 3 instances of eQEP on AM64x. Only EQEP0 signals
can be routed to the user expansion so enable only EQEP0
in k3-am642-sk.dts.
Signed-off-by: Judith Mendez <jm@ti.com>
Link: https://lore.kernel.org/r/20240924220700.886313-6-jm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a 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 rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20241003170118.24932-5-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
External interfaces should be disabled at the SoC DTSI level, since
the node is incomplete. Disable Ethernet switch and ports in SoC DTSI
and enable them in the board DTS. If the board DTS includes a SoM DTSI
that completes the node description, enable the Ethernet switch and
ports in SoM DTSI.
Reflect this change in SoM DTSIs by removing ethernet port disable.
Signed-off-by: Logan Bristol <logan.bristol@utexas.edu>
Acked-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Acked-by: Josua Mayer <josua@solid-run.com>
Link: https://lore.kernel.org/r/20240809135753.1186-1-logan.bristol@utexas.edu
Signed-off-by: Nishanth Menon <nm@ti.com>
As described in the binding document for the "current-speed" property:
"This should only be present in case a driver has no chance to know the
baud rate of the slave device."
This is not the case for the UART used in K3 devices, the current
baud-rate can be calculated from the registers. Having this property
has the effect of actually skipping the baud-rate setup in some drivers
as it assumes it will already be set to this rate, which may not always
be the case.
It seems this property's purpose was mistaken as selecting the desired
baud-rate, which it does not. It would have been wrong to select that
here anyway as DT is not the place for configuration, especially when
there are already more standard ways to set serial baud-rates.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185441.29656-2-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Move bus-width property to *main.dtsi, above the OTAP/ITAP
delay values. While there is no error with where it is
currently at, it is easier to read the MMC node if the
bus-width property is located above the OTAP/ITAP delay
values consistently across MMC nodes.
Add missing bus-width for MMC2 in k3-am62-main.
Signed-off-by: Judith Mendez <jm@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240213235701.2438513-9-jm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Remove DLL properties which are not applicable for soft PHYs
since these PHYs do not have a DLL to enable.
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> # Verdin AM62
Signed-off-by: Judith Mendez <jm@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240213235701.2438513-7-jm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Modify license to include dual licensing as GPL-2.0-only OR MIT
license for SoC and TI evm device tree files. This allows for Linux
kernel device tree to be used in other Operating System ecosystems
such as Zephyr or FreeBSD.
While at this, update the GPL-2.0 to be GPL-2.0-only to be in sync
with latest SPDX conventions (GPL-2.0 is deprecated).
While at this, update the TI copyright year to sync with current year
to indicate license change (and add it at least for one file which was
missing TI copyright).
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Roger Quadros <rogerq@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Acked-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20240122145539.194512-6-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Each "mboxes" item is composed of two cells. It seems these got split
as they appeared to be two items in an array, but are actually a single
two-cell item. Rejoin these cells.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123222536.875797-2-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
SDHCI nodes defined in the top-level AM64 SoC dtsi files are incomplete
and will not be functional unless they are extended.
As the attached SD/eMMC is only known about at the board integration level,
these nodes should only be enabled when provided with this information.
Disable the SDHCI 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>
Link: https://lore.kernel.org/r/20231117163339.89952-2-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
bootph-all as phase tag was added to dt-schema
(dtschema/schemas/bootph.yaml) to describe various node usage during
boot phases with DT.
Describe the same for AM642-sk boot devices.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911172902.1057417-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
TSCADC nodes defined in the top-level AM64 SoC dtsi files are incomplete
and may not be functional unless they are extended with pinmux and/or
device information.
Disable the TSCADC 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>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230810003814.85450-14-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
OSPI nodes defined in the top-level AM64 SoC dtsi files are incomplete
and may not be functional unless they are extended with pinmux and
device information.
As the attached OSPI device is only known about at the board integration
level, these nodes should only be enabled when provided with this
information.
Disable the OSPI 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>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230810003814.85450-8-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The DTS uses constants for SERDES MUX idle state values which were earlier
provided as bindings header. But they are unsuitable for bindings.
So move these constants in a header next to DTS.
Also add J784S4 SERDES4 lane definitions which were missed earlier.
Suggested-by: Nishanth Menon <nm@ti.com>
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Suggested-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/linux-arm-kernel/b24c2124-fe3b-246c-9af9-3ecee9fb32d4@kernel.org/
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20230721125732.122421-2-j-choudhary@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Prepare for pinctrl-single yaml binding and unify pin group node names.
Let's standardize on pin group node naming ending in -pins. As we don't
necessarily have a SoC specific compatible property for pinctrl-single.
I'd rather not add a pattern match for pins somewhere in the name for all
the users.
Trying to add matches for pins-default will be futile as on the earlier
SoCs we've already seen names like pins-sleep, pins-idle, pins-off and so
on that would need to be matched.
And as the node is a pin group, let's prefer to use naming -pins rather
than -pin as more pins may need to be added to the pin group later on.
Signed-off-by: Tony Lindgren <tony@atomide.com>
[vigneshr@ti.com: Rebase onto latest ti/next and extend to new nodes]
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Using a phandle makes it clear which UART we are choosing without needing
to resolve through an alias first.
Especially useful for boards like the TI J721s2-EVM where the alias is
"serial2" but it actually resolves to the 8th UART instance(main_uart8).
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230601184933.358731-2-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
As the binding for "current-speed" states, this should only be used
when the baud rate of an attached device cannot be detected. This is
the case for our attached on-board USB-to-UART converter used for
early kernel console. For all other unconnected/disabled ports this
can be configured in userspace later, DT is not the place for device
configuration, especially when there are already standard ways to
set serial baud in userspace.
Remove setting baud for all disabled serial ports and move setting
it for the couple enabled ports down into the board files.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230601184933.358731-1-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-12-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Describe OSPI flash partition information through device tree, this
helps to remove passing partition information through the mtdparts
commandline parameter which requires maintaining the partition
information in a string format. AM64 SK and EVM has a S28 64 MiB OSPI
flash with sector size of 256 KiB thus the size of the smallest partition
is chosen as 256 KiB, the partition names and offsets are chosen according
to the corresponding name and offsets in bootloader.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513141712.27346-6-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Mailbox nodes defined in the top-level AM64x SoC dtsi files are incomplete
and may not be functional unless they are extended with a chosen interrupt
and connection to a remote processor.
As the remote processors depend on memory nodes which are only known at
the board integration level, these nodes should only be enabled when
provided with the above information.
Disable the Mailbox nodes in the dtsi files and only enable the ones that
are actually used on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-4-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Drop bootargs and add aliases based on base pinout of SK as per [1] and
evm per [2].
Indices chosen attempt to maintain some level of consistency with
existing aliases.
While at this, drop a extra EoL. While this patch could be split, it
seems trivial to add additional cleanup steps.
[1] https://www.ti.com/lit/df/sprr432/sprr432.pdf
[2] https://www.ti.com/lit/zip/swrr171
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230414073328.381336-11-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Rename the regulator node names to the standard regulator-0.. numbers.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230414073328.381336-6-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Describe the main_uart1 pins even though it is a reserved node for
hardware complete description. This is used by other users of device
tree to help configure the SoC per board requirements.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230414073328.381336-5-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable AT24C512C on the base board.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230414073328.381336-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Fix the pinmux for pulldirection to get stable sdcard behavior.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230414073328.381336-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The GPMC node defined in the top-level AM64x SoC dtsi files are incomplete
and will not be functional unless it is extended with pinmux information.
As the pinmux is only known at the board integration level, this node
should only be enabled when provided with this information.
Disable the GPMC node in the dtsi file. Since the ELM is made to work
with the GPMC, disable it too.
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-11-afd@ti.com
MCAN 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 MCAN 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-10-afd@ti.com
MDIO nodes defined in the top-level AM64x SoC dtsi files are incomplete
and will not be functional unless they are extended with a pinmux.
As the attached PHY is only known about at the board integration level,
these nodes should only be enabled when provided with this information.
Disable the MDIO nodes (in both CPSW and ICSSG) 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-9-afd@ti.com
Although usually integrated as a child of an Ethernet controller, MDIO
IP has an independent pinout. This pinout should be controlled by
the MDIO node (so if it was to be disabled for instance, the pinmux
state would reflect that).
Move the MDIO pins pinmux to the MIDO nodes.
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-8-afd@ti.com
PCIe nodes defined in the top-level AM64x SoC dtsi files are incomplete
and will not be functional unless they are extended with a SerDes PHY.
And usually only one of the two modes can be used at a time as they
share a SerDes link.
As the PHY and mode is only known at the board integration level, these
nodes should only be enabled when provided with this information.
Disable the PCIe 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-7-afd@ti.com
ECAP nodes defined in the top-level AM64x SoC dtsi files are incomplete
and will not be functional unless they are extended with pinmux
information. (These and the EPWM nodes could be used to trigger internal
actions but they are not used like that currently)
As the pinmux is only known at the board integration level, these
nodes should only be enabled when provided with this information.
Disable the ECAP 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-6-afd@ti.com
EPWM 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 EPWM 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-5-afd@ti.com
SPI 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 SPI 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-4-afd@ti.com
I2C 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 I2C 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-3-afd@ti.com
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
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
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
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
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
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
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 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
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
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
