Currently, DS_IO_OVERRIDE_EN_SHIFT macro is not defined anywhere but
used for defining other macro.
Replace this undefined macro with valid macro. Rename the existing macro
to reflect the actual behavior.
Fixes: 325aa0f6b3 ("arm64: dts: ti: k3-pinctrl: Introduce deep sleep macros")
Reviewed-by: Kendall Willis <k-willis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Fixes: 325aa0f6b3 ("arm64: dts: ti: k3-pinctrl: Introduce deep sleep macros")
Link: https://patch.msgid.link/20250909044108.2541534-5-a-kaur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add the drive strength, schmitt trigger enable macros to pinctrl file.
Add the missing macros for DeepSleep configuration control referenced
from "Table 14-8769. Description Of The Pad Configuration Register Bits"
in AM62Px TRM[0].
Add some DeepSleep macros to provide combinations that can be used
directly in device tree files example PIN_DS_OUTPUT_LOW that
configures pin to be output and also sets its value to 0.
[0] https://www.ti.com/lit/pdf/SPRUJ83
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Link: https://patch.msgid.link/20250909044108.2541534-4-a-kaur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
After the SoC has entered the DeepSleep low power mode, USB1 can be
used to wakeup the SoC based on USB events triggered by USB devices.
This requires that the pin corresponding to the Type-A connector
remains pulled up even after the SoC has entered the DeepSleep low power
mode.
For that, either DeepSleep pullup configuration can be selected or the pin
can have the same configuration that it had when SoC was in active mode.
Remove the unnecessary DeepSleep state configuration from USB1_DRVBUS pin,
as the DeepSleep control bit is not set and the active configuration is
sufficient to keep the pin pulled up. This simplifies the setup and removes
redundant configuration.
This reverts commit 527f884d2d.
Tested-by: Kendall Willis <k-willis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Acked-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250909044108.2541534-3-a-kaur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
After the SoC has entered the DeepSleep low power mode, USB1 can be used
to wakeup the SoC based on USB events triggered by USB devices. This
requires that the pin corresponding to the Type-A connector remains pulled
up even after the SoC has entered the DeepSleep low power mode.
For that, either DeepSleep pullup configuration can be selected or the pin
can have the same configuration that it had when SoC was in active mode.
Remove the unnecessary DeepSleep state configuration from USB1_DRVBUS pin,
as the DeepSleep control bit is not set and the active configuration is
sufficient to keep the pin pulled up. This simplifies the setup and removes
redundant configuration.
This reverts commit 115290c112.
Tested-by: Kendall Willis <k-willis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Acked-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250909044108.2541534-2-a-kaur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
This patch adds the dt for SK-AM62-SIP, which uses the existing
SK-AM62 board design with the new AM6254atl SiP. This changes the
location of memory node from the board dts to SoC level dtsi
(k3-am6254atl in our case).
Therefore this patch introduces the new 'k3-am625-sk-common.dtsi'
which represents the common hardware used for both 'am625-sk' and
'am6254atl-sk' boards with the inheritance hierarchy modified to:
k3-am625-sk.dts:
k3-am62 k3-am62x-sk-common
| |
k3-am625 k3-am625-sk-common
| |
+-----+------+
|
k3-am625-sk
k3-am6254atl-sk.dts:
k3-am62
|
k3-am625 k3-am62x-sk-common
| |
k3-am6254atl k3-am625-sk-common
| |
+-------+--------+
|
k3-am6254atl-sk
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-5-anshuld@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The k3-am62x-sk-common dtsi represents the common hardware used across
am62x EVMs which can be configured with various DDR sizes or none (with
DDR integrated in the package) based on the specific am62x SoC used.
Therefore this patch moves the memory node and the SoC specific k3-am625
dtsi out of sk-common and into the board dts files. No functional change
is intended from this patch. The device-tree inheritance is changed as
follows:
Before:
k3-am62
^
k3-am625
^
k3-am62x-sk-common
^
am62x EVMs (k3-am625-sk, k3-am62-lp-sk)
After:
k3-am62
^
k3-am625 k3-am62x-sk-common
^ ^
am62x EVMs (k3-am625-sk, k3-am62-lp-sk)
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-2-anshuld@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 AM65 SoCs have multiple programmable remote processors like
R5Fs. The TI SDKs for AM65 SoCs offer sample firmwares which could be
run on these cores to demonstrate an "echo" IPC test. Those firmware
require certain memory carveouts to be reserved from system memory,
timers to be reserved, and certain mailbox configurations for interrupt
based messaging. These configurations could be different for a different
firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-35-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 AM64 SoCs have multiple programmable remote processors like
R5F, M4F etc. The TI SDKs for AM64 SoCs offer sample firmwares which
could be run on these cores to demonstrate an "echo" IPC test. Those
firmware require certain memory carveouts to be reserved from system
memory, timers to be reserved, and certain mailbox configurations for
interrupt based messaging. These configurations could be different for a
different firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de> # phycore-am64x
Tested-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de> # phycore-am64x
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-34-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 AM62A SoCs have multiple programmable remote processors like
R5F, C7x etc. The TI SDKs for AM62A SoCs offer sample firmwares which
could be run on these cores to demonstrate an "echo" IPC test. Those
firmware require certain memory carveouts to be reserved from system
memory, timers to be reserved, and certain mailbox configurations for
interrupt based messaging. These configurations could be different for a
different firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Judith Mendez <jm@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-33-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 AM62 SoCs have multiple programmable remote processors like
R5F, M4F etc. The TI SDKs for AM62 SoCs offer sample firmwares which
could be run on these cores to demonstrate an "echo" IPC test. Those
firmware require certain memory carveouts to be reserved from system
memory, timers to be reserved, and certain mailbox configurations for
interrupt based messaging. These configurations could be different for a
different firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de> # phycore-am62x
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-32-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 AM62P SoCs have multiple programmable remote processors like
R5Fs. The TI SDKs for AM62P SoCs offer sample firmwares which could be
run on these cores to demonstrate an "echo" IPC test. Those firmware
require certain memory carveouts to be reserved from system memory,
timers to be reserved, and certain mailbox configurations for interrupt
based messaging. These configurations could be different for a different
firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Judith Mendez <jm@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-31-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 J722S SoCs have multiple programmable remote processors like
R5F, C7x etc. The TI SDKs for J722S SoCs offer sample firmwares which
could be run on these cores to demonstrate an "echo" IPC test. Those
firmware require certain memory carveouts to be reserved from system
memory, timers to be reserved, and certain mailbox configurations for
interrupt based messaging. These configurations could be different for a
different firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-30-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 J784S4 SoCs have multiple programmable remote processors like
R5F, C7x etc. The TI SDKs for J784S4 SoCs offer sample firmwares which
could be run on these cores to demonstrate an "echo" IPC test. Those
firmware require certain memory carveouts to be reserved from system
memory, timers to be reserved, and certain mailbox configurations for
interrupt based messaging. These configurations could be different for a
different firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
This patch only refactors the C71_3 remote processor related nodes into
the new dtsi. All other nodes have been refactored in the previous
commit as part of k3-j784s4-j742s2-ti-ipc-firmware-common.dtsi.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-29-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 J784S4/J742S2 SoCs have multiple programmable remote
processors like R5F, C7x etc. The TI SDKs for J784S4/J742S2 SoCs offer
sample firmwares which could be run on these cores to demonstrate an
"echo" IPC test. Those firmware require certain memory carveouts to be
reserved from system memory, timers to be reserved, and certain mailbox
configurations for interrupt based messaging. These configurations could
be different for a different firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-28-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 J721S2 SoCs have multiple programmable remote processors like
R5F, C7x etc. The TI SDKs for J721S2 SoCs offer sample firmwares which
could be run on these cores to demonstrate an "echo" IPC test. Those
firmware require certain memory carveouts to be reserved from system
memory, timers to be reserved, and certain mailbox configurations for
interrupt based messaging. These configurations could be different for a
different firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-27-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 J721E SoCs have multiple programmable remote processors like
R5F, C6x, C7x etc. The TI SDKs for J721E SoCs offer sample firmwares
which could be run on these cores to demonstrate an "echo" IPC test.
Those firmware require certain memory carveouts to be reserved from
system memory, timers to be reserved, and certain mailbox configurations
for interrupt based messaging. These configurations could be different
for a different firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-26-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI K3 J7200 SoCs have multiple programmable remote processors like
R5Fs. The TI SDKs for J7200 SoCs offer sample firmwares which could be
run on these cores to demonstrate an "echo" IPC test. Those firmware
require certain memory carveouts to be reserved from system memory,
timers to be reserved, and certain mailbox configurations for interrupt
based messaging. These configurations could be different for a different
firmware.
While DT is not meant for system configurations, at least refactor these
configurations from board level DTS into a dtsi for now. This dtsi for
TI IPC firmware is board-independent and can be applied to all boards
from the same SoC Family. This gets rid of code duplication and allows
more freedom for users developing custom firmware (or no firmware) to
utilize system resources better; easily by swapping out this dtsi. To
maintain backward compatibility, the dtsi is included in all boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-25-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Switch the MAIN domain R5F clusters into split mode to maximize the
number of R5F processors. The TI IPC firmware for the split processors
is already available public. This config aligns with other J721E boards
and can be refactored out later.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-24-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
This reverts commit 1a314099b7.
The C6x carveouts are reversed intentionally. This is due to the
requirement to keep the DMA memory region as non-cached, however the
minimum granular cache region for C6x is 16MB. So, C66x_0 marks the
entire C66x_1 16MB memory carveouts as non-cached, and uses the DMA
memory region of C66x_1 as its own, and vice-versa.
This was also called out in the original commit which introduced these
reversed carveouts:
"The minimum granularity on the Cache settings on C66x DSP
cores is 16MB, so the DMA memory regions are chosen such that
they are in separate 16MB regions for each DSP, while reserving
a total of 16 MB for each DSP and not changing the overall DSP
remoteproc carveouts."
Fixes: 1a314099b7 ("arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations")
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-23-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
This reverts commit 9f3814a7c0.
The C6x carveouts are reversed intentionally. This is due to the
requirement to keep the DMA memory region as non-cached, however the
minimum granular cache region for C6x is 16MB. So, C66x_0 marks the
entire C66x_1 16MB memory carveouts as non-cached, and uses the DMA
memory region of C66x_1 as its own, and vice-versa.
This was also called out in the original commit which introduced these
reversed carveouts:
"The minimum granularity on the Cache settings on C66x DSP cores
is 16MB, so the DMA memory regions are chosen such that they are
in separate 16MB regions for each DSP, while reserving a total
of 16 MB for each DSP and not changing the overall DSP
remoteproc carveouts."
Fixes: 9f3814a7c0 ("arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations")
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-22-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Currently, only R5F remote processors are enabled for k3-am642-tqma64xxl
whereas the M4F in MCU domain is disabled. Enable the M4F remote
processor at board level by reserving memory carveouts and assigning
mailboxes.
While at it, reserve the MAIN domain timers that are used by R5F remote
processors for ticks to avoid rproc crashes. This config aligns with
other AM64 boards and can be refactored out later.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-21-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The k3-am64-phycore SoM enables all R5F and M4F remote processors.
Reserve the MAIN domain timers that are used by R5F remote
processors for ticks to avoid rproc crashes. This config aligns with
other AM64 boards and can be refactored out later.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://patch.msgid.link/20250908142826.1828676-20-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Currently, only R5F remote processors are enabled for k3-am642-sr SoMs,
whereas the M4F in MCU domain is disabled. Enable the M4F remote
processor at board level by reserving memory carveouts and assigning
mailboxes.
While at it, reserve the MAIN domain timers that are used by R5F remote
processors for ticks to avoid rproc crashes. This config aligns with
other AM64 boards and can be refactored out later.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-19-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The wkup_r5fss0_core0_memory_region is used to store the text/data
sections of the Device Manager (DM) firmware itself and is necessary for
platform boot. Whereas the wkup_r5fss0_core0_dma_memory_region is used
for allocating the Virtio buffers needed for IPC with the DM core which
could be optional. The labels were incorrectly used in the
k3-am62-pocketbeagle2.dts file. Correct the firmware memory region label
Currently, only mailbox node is enabled with FIFO assignment for a
single M4F remote core. Add the missing carveouts for WKUP R5F remote
processor, and enable that by associating to the above carveout and
mailbox. This config aligns with other AM62 boards and can be
refactored out later.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-18-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The wkup_r5fss0_core0_memory_region is used to store the text/data
sections of the Device Manager (DM) firmware itself and is necessary for
platform boot. Whereas the wkup_r5fss0_core0_dma_memory_region is used
for allocating the Virtio buffers needed for IPC with the DM core which
could be optional. The labels were incorrectly used in the
k3-am62-verdin.dtsi file. Correct the firmware memory region label.
Currently, only mailbox node is enabled with FIFO assignment for a
single M4F remote core. However, there are no users of the enabled
mailboxes. Add the missing carveouts for WKUP R5F and MCU M4F remote
processors, and enable those by associating to the above carveout and
mailboxes. This config aligns with other AM62 boards and can be
refactored out later.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Hiago De Franco <hiago.franco@toradex.com> # Verdin AM62
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20250908142826.1828676-17-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The wkup_r5fss0_core0_memory_region is used to store the text/data
sections of the Device Manager (DM) firmware itself and is necessary for
platform boot. Whereas the wkup_r5fss0_core0_dma_memory_region is used
for allocating the Virtio buffers needed for IPC with the DM core which
could be optional. The labels were incorrectly used in the
k3-am62p-verdin.dtsi file. Correct the firmware memory region label.
Currently, only mailbox node is enabled with FIFO assignment. However,
there are no users of the enabled mailboxes. Add the missing carveouts
for WKUP and MCU R5F remote processors, and enable those by associating
to the above carveout and mailboxes. This config aligns with other AM62P
boards and can be refactored out later.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Hiago De Franco <hiago.franco@toradex.com> # Verdin AM62P
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20250908142826.1828676-16-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI IPC Firmwares running on J721E SoCs use certain MAIN domain
timers as tick. Reserve those at board level DT to avoid remote
processor crashes. This config aligns with other J721E boards and can
be refactored out later.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-15-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Currently, the reserved memory carveouts used by remote processors are
named like 'rproc-name-<dma>-memory-region@addr'. While it is
descriptive, the node label already serves that purpose. Rename reserved
memory nodes to generic 'memory@addr' to align with the device tree
specifications. This is done for all TI K3 based boards.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20250908142826.1828676-14-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add the label name 'reserved_memory' to the reserved-memory node in all
K3 AM6* board level dts files. This is done so that the node can be
referenced and extended to add more carveout entries as needed in future
refactoring patches.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-13-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Mailbox nodes defined in the top-level AM62A 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: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-12-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Mailbox nodes defined in the top-level AM62x 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: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-11-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level AM65x SoC dtsi files are
incomplete without the memory carveouts and mailbox assignments which
are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable them at
board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-10-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level AM64x SoC dtsi files are
incomplete without the memory carveouts and mailbox assignments which
are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable them at
board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de> # phycore-am64x
Tested-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-9-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level AM62A SoC dtsi files are
incomplete without the memory carveouts and mailbox assignments which
are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable them at
board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-8-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level AM62x SoC dtsi files are
incomplete without the memory carveouts and mailbox assignments which
are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable them at
board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-7-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level AM62P-J722S common SoC dtsi
files are incomplete without the memory carveouts and mailbox
assignments which are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable them at
board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Judith Mendez <jm@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-6-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level J784S4-J742S2 common SoC dtsi
files are incomplete without the memory carveouts and mailbox
assignments which are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable them at
board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-5-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level J721S2 SoC dtsi files are
incomplete without the memory carveouts and mailbox assignments which
are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable them at
board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-4-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level J721E SoC dtsi files are
incomplete without the memory carveouts and mailbox assignments
which are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable
them at board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-3-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Remote Processors defined in top-level J7200 SoC dtsi files are
incomplete without the memory carveouts and mailbox assignments which
are only known at board integration level.
Therefore, disable the remote processors at SoC level and enable them at
board level where above information is available.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-2-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The J742S2 SoC reuses the common k3-j784s4-j742s2-mcu-wakeup-common.dtsi
for its MCU domain, but it does not override the firmware-name property
for its R5F cores. This causes the wrong firmware binaries to be
referenced.
Introduce a new k3-j742s2-mcu-wakeup.dtsi file to override the
firmware-name property with correct names for J742s2.
Fixes: 38fd90a3e1 ("arm64: dts: ti: Introduce J742S2 SoC family")
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://patch.msgid.link/20250823163111.2237199-1-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The SERDES0 instance of SERDES on the AM69 SoC is a Cadence Torrent SERDES
and it has 4 lanes which are allocated in the following manner:
Lane0 and Lane1 to PCIe1
Lane2 to PCIe3
Lane3 to USB0
Until [0], the Cadence Torrent SERDES driver only supported configuring
the SERDES for a PCIe + USB configuration whereby all lanes of the
SERDES configured for PCIe will operate at the same speed. As a result,
PCIe1 and PCIe3 instances of PCIe will either fall down to a common
speed based on the PCIe peers that they are each connected to, or, the
PCIe link could fail to be setup.
Since [0] enables support for PCIe Multilink + USB configuration, it is
now possible for the SERDES lanes allocated to PCIe1 and PCIe3 to link up
and operate at different speeds. USB continues to remain functional.
Hence, update the 'serdes0' node as well as the 'pcie1_rc' and 'pcie3_rc'
nodes to switch to the PCIe Multilink + USB configuration that is now
supported by the Cadence Torrent SERDES driver.
[0]: commit 351e07e6b2 ("phy: cadence-torrent: Add PCIe multilink + USB with same SSC register config for 100 MHz refclk")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250819105717.372893-1-s-vadapalli@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add missing address-cells 0 to the PCI interrupt node to silence W=1
warning:
k3-j721s2-main.dtsi:1431.3-1434.29: Warning (interrupt_map): /bus@100000/pcie@2910000:interrupt-map:
Missing property '#address-cells' in node /bus@100000/pcie@2910000/interrupt-controller, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250822133309.312189-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Nishanth Menon <nm@ti.com>
