Message-ID: <20251106101932.GA5975@francesco-nb>
Date: Thu, 6 Nov 2025 11:19:45 +0100
From: Francesco Dolcini <francesco@...cini.it>
To: Andrew Davis <afd@...com>
Cc: Francesco Dolcini <francesco@...cini.it>, Nishanth Menon <nm@...com>,
	Vignesh Raghavendra <vigneshr@...com>,
	Tero Kristo <kristo@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Parth Pancholi <parth.pancholi@...adex.com>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Emanuele Ghidoli <emanuele.ghidoli@...adex.com>,
	Ernest Van Hoecke <ernest.vanhoecke@...adex.com>,
	João Paulo Gonçalves <joao.goncalves@...adex.com>,
	Francesco Dolcini <francesco.dolcini@...adex.com>
Subject: Re: [PATCH v1 2/3] arm64: dts: ti: Add Aquila AM69 Support

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@...adex.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@...adex.com>
> > > > Co-developed-by: Emanuele Ghidoli <emanuele.ghidoli@...adex.com>
> > > > Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@...adex.com>
> > > > Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@...adex.com>
> > > > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@...adex.com>
> > > > Co-developed-by: João Paulo Gonçalves <joao.goncalves@...adex.com>
> > > > Signed-off-by: João Paulo Gonçalves <joao.goncalves@...adex.com>
> > > > Co-developed-by: Francesco Dolcini <francesco.dolcini@...adex.com>
> > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@...adex.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.

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.

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).

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

Powered by blists - more mailing lists