[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56b5bacc-7214-41aa-b969-4f622afcd9f9@oss.qualcomm.com>
Date: Fri, 12 Sep 2025 10:56:04 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
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 9/12/25 10:03 AM, 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
You have a number of features that depend on several other series, and
as Krzysztof pointed out this is difficult to merge/review.. Could you
please create a "linux-next/master-ready" version of this series and
separate the changes for which the dependencies are unmet, putting them
at the end? This way we can take at least some of your diff.
If you still want review on them, you can also send them as [PATCH DNM]
or so
Konrad
Powered by blists - more mailing lists