Re: [PATCH v1 2/3] arm64: dts: ti: Add Aquila AM69 Support
From: Andrew Davis
Date: Thu Nov 06 2025 - 08:32:49 EST
On 11/6/25 4:19 AM, Francesco Dolcini wrote:
Hello Andrew,
On Wed, Nov 05, 2025 at 02:01:35PM -0600, Andrew Davis wrote:
On 11/5/25 5:53 AM, Francesco Dolcini wrote:
On Tue, Nov 04, 2025 at 11:41:54AM -0600, Andrew Davis wrote:
On 11/4/25 8:52 AM, Francesco Dolcini wrote:
From: Parth Pancholi <parth.pancholi@xxxxxxxxxxx>
Add support for the Toradex Aquila AM69 and its Development Carrier
Board.
The Aquila AM69 SoM is based on the TI AM69 SoC from the Jacinto 7
family and is designed for high-end embedded computing, featuring up to
32GB of LPDDR4 and 256GB eMMC storage, extensive multimedia support (3x
Quad CSI, 2x Quad DSI, DisplayPort, 5x Audio I2S/TDM), six Ethernet
interfaces (1x 1G, 4x 2.5G SGMII, 1x 10G), USB 3.2 Host/DRD support, and
a Wi-Fi 7/BT 5.3 module, alongside an RX8130 RTC, I2C EEPROM and
Temperature Sensor, and optional TPM 2.0 module.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/ti-am69
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Signed-off-by: Parth Pancholi <parth.pancholi@xxxxxxxxxxx>
Co-developed-by: Emanuele Ghidoli <emanuele.ghidoli@xxxxxxxxxxx>
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@xxxxxxxxxxx>
Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@xxxxxxxxxxx>
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@xxxxxxxxxxx>
Co-developed-by: João Paulo Gonçalves <joao.goncalves@xxxxxxxxxxx>
Signed-off-by: João Paulo Gonçalves <joao.goncalves@xxxxxxxxxxx>
Co-developed-by: Francesco Dolcini <francesco.dolcini@xxxxxxxxxxx>
Signed-off-by: Francesco Dolcini <francesco.dolcini@xxxxxxxxxxx>
---
arch/arm64/boot/dts/ti/Makefile | 1 +
arch/arm64/boot/dts/ti/k3-am69-aquila-dev.dts | 576 ++++++
arch/arm64/boot/dts/ti/k3-am69-aquila.dtsi | 1840 +++++++++++++++++
3 files changed, 2417 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am69-aquila-dev.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am69-aquila.dtsi
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 361248dcfff4..6ce652fe98fa 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -153,6 +153,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-tevi-ov5640.dtbo
# Boards with J784s4 SoC
+dtb-$(CONFIG_ARCH_K3) += k3-am69-aquila-dev.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am69-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am69-sk-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am69-aquila-dev.dts b/arch/arm64/boot/dts/ti/k3-am69-aquila-dev.dts
new file mode 100644
index 000000000000..c7ce804eac70
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am69-aquila-dev.dts
@@ -0,0 +1,576 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (C) 2025 Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/ti-am69
+ * https://www.toradex.com/products/carrier-board/aquila-development-board-kit
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include "k3-am69-aquila.dtsi"
+
[...]
+/* Aquila SPI_2 */
+&main_spi0 {
+ status = "okay";
+};
+
+/* Aquila SPI_1 */
+&main_spi2 {
+ status = "okay";
Why enable this with nothing connected to it?
It's a development carrier board, the SPI pins go to a pins header,
accessible to the user, where anything can be hooked up for
prototyping/testing.
Sure, and when a device is attached to that pin header it will need
described in DT with a node for that attached device and in that
node/overlay is where you enable the nodes you make use of.
One use case would be to just bind this in userspace to spidev for some
prototyping/testing.
But you are not adding a spidev node here, you are attaching nothing
but enabling the node anyway.
The idea would be that you can bind the spidev driver from userspace,
without having to change anything in the DT. For this to be possible the
SPI node must be enabled.
My understanding is that this should be possible, and it's the suggested
way to debug/prototype anything with spidev. If my understanding is not
correct, I agree with you and there is no point in enabling this node.
[...]
+/* Aquila SPI_1 */
+&main_spi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_main_spi2>, <&pinctrl_main_spi2_cs0>;
+ status = "disabled";
This is already disabled by default in the SoC dtsi file.
Yes, known. Is this an issue?
This node must be disabled, no matter what is present in any included
dtsi file, it's a deliberate decision.
This dtsi file describes a SoM, the used pins/functions are defined on
the pinout, but this node cannot be enabled unless the SoM is mated with
a carrier board that is exposing it.
Same as my point above, you shouldn't enable nodes that are not used
or have anything attached. The SoM only has some edge connectors so
it should not be enabled at the SoM level, that we seem to agree, but
the carrier board doesn't connect those lines to anything either. They
just run to a pin header with nothing attached, how is that header
any different than the pins on the edge of the SoM?
You are commenting something unrelated here, or I am not understanding
you.
Yes this was a bit of a tangent to the comment above. The point here
was more on the pinmux, as a new carrier board might use these pins
for something other than SPI, the pinmuxing shouldn't be done at the
SoM dtsi level. Instead do it at the point the node is connected to
some hardware on the carrier board in its DTS.
You commented that the status = "disabled" is redundant. We both agree
that this node needs to be disabled in the SoM dtsi, and it is already
like that.
I would prefer to keep the redundant "disabled", because I see value on
not having to rely on what is done on any included dtsi, where the
original node is defined. I see this as a common pattern in multiple
dts/dtsi file and is what I would prefer to have (and I do not see any
kind of maintenance overhead on having it nor this being in conflict
with dts-coding-style.rst).
We do make sure to disable nodes in base files that are incomplete and
only enable them at the time they become complete. But if you have a
strong preference for having this redundant status then I won't object.
Andrew
Vignesh, Nishanth, what is your expectation on this redundant
`status = "disabled"` property?
Francesco
Anyway, the right spot to enable would be when you bind a device to
the SPI, which it seems you do in overlays[0], so that would be were
you set status = "okay" and all the pinmux info for that SPI device
and carrier board combination.
[0] https://developer.toradex.com/torizon/os-customization/use-cases/device-tree-overlays-on-torizon/#spidev