Re: [PATCH v1 2/3] arm64: dts: ti: Add Aquila AM69 Support

[Andrew Davis <afd@ti.com>]

On 11/5/25 5:53 AM, Francesco Dolcini wrote:
> Hello Andrew,
> thanks for the review
> 
> 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@toradex.com>
>>>
>>> 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@toradex.com>
>>> Co-developed-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
>>> Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
>>> Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>>> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>>> Co-developed-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
>>> Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
>>> Co-developed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
>>> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
>>> ---
>>>    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.

> 
>> [...]
>>
>>> +/* 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?

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.

Andrew

[0] https://developer.toradex.com/torizon/os-customization/use-cases/device-tree-overlays-on-torizon/#spidev

> 
> Francesco
>