| Age | Commit message (Collapse) | Author |
|---|
|
The IEP0 SYNC_OUT0 pins are used for PPS out on AM64 EVM.
Configure its PINMUX here.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Link: https://lore.kernel.org/r/20240614100829.3919008-1-danishanwar@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The NAND expansion card plugs in over the HSE (High Speed Expansion)
connector. Add support for it.
We add the ranges property to the GPMC node instead of the NAND
overlay file to prevent below warnings.
/fragment@3/__overlay__: Relying on default #address-cells value
/fragment@3/__overlay__: Relying on default #size-cells value
As GPMC is dedicated for NAND use on this board, it should be OK.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240614-am642-evm-nand-v5-1-acf760896239@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@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>
|
|
The am642-evm doesn't allow to enable 2 x CPSW3g ports and 2 x ICSSG1 ports
all together, so base k3-am642-evm.dts enables by default 2 x CPSW3g ports
and 1 x ICSSG1 ports, but it is also possible to support 1 x CPSW3g ports
and 2 x ICSSG1 ports configuration.
This patch adds overlay to support 1 x CPSW3g ports and 2 x ICSSG1 ports
configuration:
- Add label name 'mdio_mux_1' for 'mdio-mux-1' node so that the node
'mdio-mux-1' can be disabled in the overlay using the label name.
- disable 2nd CPSW3g port
- update CPSW3g pinmuxes to not use RGMII2
- disable mdio-mux-1 and define mdio-mux-2 to route ICSSG1 MDIO to the
shared DP83869 PHY
- add and enable ICSSG1 RGMII2 pinmuxes
- enable ICSSG1 MII1 port
Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Link: https://lore.kernel.org/r/20240215103036.2825096-4-danishanwar@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
ICSSG1 provides dual Gigabit Ethernet support with proper FW loaded.
The ICSSG1 MII0 (RGMII1) has DP83869 PHY attached to it. The ICSSG1 shares
MII1 (RGMII2) PHY DP83869 with CPSW3g and it's assigned by default to
CPSW3g. The MDIO access to MII1 (RGMII2) PHY DP83869 is controlled by MDIO
bus switch and also assigned to CPSW3g. Therefore the ICSSG1 MII1 (RGMII2)
port is kept disable and ICSSG1 is enabled in single MAC mode by
default.
Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Link: https://lore.kernel.org/r/20240215103036.2825096-3-danishanwar@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Add missing bootph-all property for AM62p MMC0 and AM64x
MMC0 nodes.
Signed-off-by: Judith Mendez <jm@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240213235701.2438513-10-jm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@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>
|
|
This node is an example node for the PCIe controller in "endpoint" mode.
By default the controller is in "root complex" mode and there is already a
DT node for the same.
Examples should go in the bindings or other documentation.
Remove this node.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240124183659.149119-4-afd@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-1-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>
|
|
Similar to MCU GPIO, mark the MCU GPIO router also as reserved for MCU
domain firmware usage.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20231110132508.3137454-1-vigneshr@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
A TCA9554 GPIO expander is present on I2C0. Add it.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230923080046.5373-3-rogerq@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@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-evm boot devices.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911172902.1057417-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@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-11-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>
|
|
Hold the DDR vtt regulator active for functionality.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230414073328.381336-10-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-9-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-8-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Enable AT24CM01 on the base board using the corresponding compatible.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230414073328.381336-7-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
|
|
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
|
|
The GPMC is a unified memory controller dedicated for interfacing
with external memory devices like
- Asynchronous SRAM-like memories and ASICs
- Asynchronous, synchronous, and page mode burst NOR flash
- NAND flash
- Pseudo-SRAM devices
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20220802104456.11069-2-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
|
|
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
|
|
EVM and disable them on SK
AM642 EVM has two CAN connecters brought out from the two MCAN instances in
the main domain through transceivers. Add device tree nodes for
transceivers and set the required properties in the mcan device tree nodes,
in EVM device tree file.
On AM642 SK there are no connectors brought out for CAN. Therefore, disable
the mcan device tree nodes in the SK device tree file.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20211122134159.29936-7-a-govindraju@ti.com
|
|
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 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
|
|
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
|
|
dt-shema
ti,pindir-d0-out-d1-in property is expected to be of type boolean.
Therefore, fix the property accordingly.
Fixes: 4fb6c04683aa ("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
|
|
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
|
