[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1358ccb9-b8d3-4e5e-a2d9-eefc8be6b75e@kernel.org>
Date: Fri, 12 Sep 2025 10:16:43 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Xilin Wu <sophon@...xa.com>, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Neil Armstrong <neil.armstrong@...aro.org>,
Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>,
Ram Kumar Dwivedi <quic_rdwivedi@...cinc.com>
Subject: Re: [PATCH RFC 0/2] arm64: dts: qcom: qcs6490: Introduce Radxa Dragon
Q6A
On 12/09/2025 10:03, Xilin Wu wrote:
> Radxa Dragon Q6A (https://docs.radxa.com/en/dragon/q6a) is a single board
> computer, based on the Qualcomm QCS6490 platform.
>
> The board ships with a modified version of the Qualcomm Linux boot
> firmware, which is stored on the onboard SPI NOR flash. This allows
> booting standard EFI-based bootloaders from SD/eMMC/USB/UFS/NVMe. It
> supports replaceable UFS 3.1/eMMC modules for easy user upgrades.
>
> The board schematic is available at [1].
>
> Features enabled and working:
>
> - USB-A 3.0 port (depends on [2])
> - Three USB-A 2.0 ports
> - RTL8111K Ethernet connected to PCIe0
> - UFS 3.1 module (depends on [3])
> - eMMC module
> - SD card
> - M.2 M-Key 2230 PCIe 3.0 x2
> - HDMI 2.0 port including audio (depends on [2])
> - Configurable I2C/SPI/UART from 40-Pin GPIO (depends on [4])
> - Headphone jack
> - Onboard thermal sensors
> - QSPI controller for updating boot firmware
> - ADSP remoteproc (Type-C and charging features disabled in firmware)
> - CDSP remoteproc (for AI applications using QNN)
> - Venus video encode and decode accelerator
>
> Features available with additional DT overlays:
> - CSI cameras
> - DSI display
>
> ALSA UCM and Audioreach topology patches are available at [5] and [6].
>
> This series is posted as an RFC because it depends on several other patch series.
Ah, here it is. That's the most important information, so should be
placed at the top. You do not put the most important information hidden
somewhere in the mail.
Question about dependencies stays, though...
Best regards,
Krzysztof
Powered by blists - more mailing lists