| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add WDT0-5 nodes to RZ/T2H (R9A09G077) SoC DTSI.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250821161946.1096033-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable SD card slot which is connected to SDHI0 on the RZ/T2H and
RZ/N2H EVKs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250820200659.2048755-10-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable MicroSD card slot which is connected to SDHI1 on the RZ/T2H and
RZ/N2H EVKs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250820200659.2048755-9-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable eMMC on RZ/T2H and RZ/N2H EVKs. As SDHI0 can be connected to
either eMMC0/SD0 `SD0_EMMC` macro is added.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250820200659.2048755-8-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The J721S2-EVM (J721S2-SOM mounted on the J7 Common Processor Board) has
a single instance of USB namely USB0. On the board, USB0 can be enabled
using a single USB interface at a time among the following:
1. USB3.1 Gen1 Type C interface
2. Two USB2.0 Type A interfaces via an on-board USB Hub
By default, USB0 is enabled using the USB3.1 Gen1 Type C interface. Hence,
add a device-tree overlay to allow using USB0 with the USB2.0 Type A
interfaces by configuring the "USB2.0_MUX_SEL" mux. Also, since the Type A
interfaces only connect to USB Devices with USB0 acting as the USB Host,
set the Dual-Role mode for USB0 to Host.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250912062021.2906034-1-s-vadapalli@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The PEB-C-010 expansion board adds two extra 1Gbps ethernet ports to
the phyBOARD-Electra-AM64x.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://patch.msgid.link/20250910141716.2133707-1-w.egorov@phytec.de
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add device tree support for the Variscite Symphony carrier board with
the VAR-SOM-AM62P system on module.
The Symphony board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart interfaces
- OV5640 Camera support
- GPIO Expander
- CAN, I2C and general purpose interfaces
Link: https://www.variscite.it/product/single-board-computers/symphony-board/
Signed-off-by: Stefano Radaelli <stefano.radaelli21@gmail.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250909213749.28098-4-stefano.radaelli21@gmail.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add device tree support for the Variscite VAR-SOM-AM62P system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- AM62P Sitara MPU processor
- Up to 8GB of DDR4-3733 memory
- eMMC storage memory
- PS6522430 chip as a Power Management Integrated circuit (PMIC)
- Integrated 10/100/1000 Mbps Ethernet Transceiver Analog Devices ADIN1300
- Resistive touch panel interface controller TI TSC2046
- I2C interfaces
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://www.variscite.it/product/system-on-module-som/cortex-a53-krait/var-som-am62p-ti-sitara-am62px/
Signed-off-by: Stefano Radaelli <stefano.radaelli21@gmail.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250909213749.28098-3-stefano.radaelli21@gmail.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add bootph-all property to the USB0 PHY controller node to make it
available during all boot phases. This is required for USB DFU boot.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250902053009.1732607-5-h-salunke@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add bootph-all property to the USB0 PHY controller node to make it
available during all boot phases. This is required for USB DFU boot.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250902053009.1732607-4-h-salunke@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add bootph-all property to the USB0 PHY controller node to make it
available during all boot phases. This is required for USB DFU boot.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250902053009.1732607-3-h-salunke@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add bootph-all property to the USB0 PHY controller node to make it
available during all boot phases. This is required for USB DFU boot.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250902053009.1732607-2-h-salunke@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
TI's J721E SoC supports a DPI to DSI video signal conversion bridge on
it's platform bus. The IP is from Cadence, and it has a custom TI
wrapper around it to facilitate integration.
This IP takes the DPI video signals from DSS and alongwith the DPHY IP,
it transmits DSI video signals out of the SoC.
Add support for DSI bridge and the DPHY-TX.
Signed-off-by: Rahul T R <r-ravikumar@ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Harikrishna Shenoy <h-shenoy@ti.com>
Link: https://patch.msgid.link/20250905094325.472473-1-h-shenoy@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
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: 325aa0f6b36e ("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: 325aa0f6b36e ("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 527f884d2d94981016e181dcbd4c4b5bf597c0ad.
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 115290c112952db27009668aa7ae2f29920704f0.
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>
|
|
Add support for the BQ25703A charger manager and boost regulator to
the Gameforce Ace. Add the USB-C port and PHY as well as they all
depend on each other for operation.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20250904160530.66178-6-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The first SCP core is used to drive the video decoder and encoders.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20250814092510.211672-1-wenst@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The touchscreen controller used with the original Krabby design is the
Elan eKTH6918, which is in the same family as eKTH6915, but supporting
a larger screen size with more sense lines.
OTOH, the touchscreen controller that actually shipped on the Tentacruel
devices is the Elan eKTH6A12NAY. A compatible string was added for it
specifically because it has different power sequencing timings.
Fix up the touchscreen nodes for both these. This also includes adding
a previously missing reset line. Also add "no-reset-on-power-off" since
the power is always on, and putting it in reset would consume more
power.
Fixes: 8855d01fb81f ("arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / Tentacool")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20250812090135.3310374-1-wenst@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The efuse block in the MT8188 contains the GPU speed bin cell, and like
the MT8186 one, has the same conversion scheme to work with the GPU OPP
binding. This was reflected in a corresponding change to the efuse DT
binding.
Change the fallback compatible of the MT8188's efuse block from the
generic one to the MT8186 one. This also makes GPU DVFS work properly.
Fixes: d39aacd1021a ("arm64: dts: mediatek: mt8188: add lvts definitions")
Fixes: 50e7592cb696 ("arm64: dts: mediatek: mt8188: Add GPU speed bin NVMEM cells")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250610063431.2955757-3-wenst@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
AM62D2 EVM has S28HS512T 64 MiB Octal SPI NOR flash connected to the
OSPI interface. Add support for the flash and describe the partition
information as per bootloader.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Santhosh Kumar K <s-k6@ti.com>
Link: https://patch.msgid.link/20250813090300.733295-1-p-bhagat@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add pinmux configuration for USB1 interface and enable the node for
functionality. Also enable data transfer on USB0, on existing power
delivery configuration.
Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Hrushikesh Salunke <h-salunke@ti.com>
Link: https://patch.msgid.link/20250903062513.813925-3-p-bhagat@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The main pad configuration register region starts with the register
MAIN_PADCFG_CTRL_MMR_CFG0_PADCONFIG0 with address 0x000f4000 and ends
with the MAIN_PADCFG_CTRL_MMR_CFG0_PADCONFIG150 register with address
0x000f4258, as a result of which, total size of the region is 0x25c
instead of 0x2ac.
Reference Docs
TRM (AM62A) - https://www.ti.com/lit/ug/spruj16b/spruj16b.pdf
TRM (AM62D) - https://www.ti.com/lit/ug/sprujd4/sprujd4.pdf
Fixes: 5fc6b1b62639c ("arm64: dts: ti: Introduce AM62A7 family of SoCs")
Cc: stable@vger.kernel.org
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250903062513.813925-2-p-bhagat@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
STRB setting for eMMC HS400 have been updated in device datasheet [0],
so update for am62p in k3-am62p-main.
[0] https://www.ti.com/lit/gpn/am62p
Signed-off-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250908235207.473628-3-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Since eMMC HS400 has been descoped for J722s due to errata i2478 [0]
and is supported for AM62Px device, remove eMMC HS400 support from
common-main.dtsi and include only in am62p-main.dtsi.
[0] https://www.ti.com/lit/pdf/sprz575
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Moteen Shah <m-shah@ti.com>
Link: https://patch.msgid.link/20250908235207.473628-2-jm@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>
|
|
This patch adds the top level dtsi for AM6254atl SiP which integrates
the existing AM625 SoC with 512MiB of DDR in a single package.
More information about the package can be found here:
https://www.ti.com/lit/ds/symlink/am625sip.pdf
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-4-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>
|
|
A previous commit changed the '#sound-dai-cells' property for the
kirkwood audio controller from 1 to 0 in the kirkwood.dtsi file,
but did not update the corresponding 'sound-dai' property in the
kirkwood-openrd-client.dts file.
This created a mismatch, causing a dtbs_check validation error where
the dts provides one cell (<&audio0 0>) while the .dtsi expects zero.
Remove the extraneous cell from the 'sound-dai' property to fix the
schema validation warning and align with the updated binding.
Fixes: e662e70fa419 ("arm: dts: kirkwood: fix error in #sound-dai-cells size")
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
Add missing address-cells 0 to the ICU interrupt node to silence W=1
warning:
armada-cp11x.dtsi:547.3-47: Warning (interrupt_map): /cp0-bus/pcie@f2600000:interrupt-map:
Missing property '#address-cells' in node /cp0-bus/bus@f2000000/interrupt-controller@1e0000/interrupt-controller@10, 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>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
address cells
Add missing address-cells 0 to the PCI interrupt node to silence W=1
warning:
armada-37xx.dtsi:518.4-521.29: Warning (interrupt_map): /soc/pcie@d0070000:interrupt-map:
Missing property '#address-cells' in node /soc/pcie@d0070000/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>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.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>
|
|
into new dtsi
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>
|
|
locations"
This reverts commit 1a314099b7559690fe23cdf3300dfff6e830ecb1.
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: 1a314099b755 ("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 9f3814a7c06b7c7296cf8c1622078ad71820454b.
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: 9f3814a7c06b ("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>
|
