[PATCH 0/6] arm64: qcom: Enable additional hardware on Radxa Dragon Q6A

[PATCH 0/6] arm64: qcom: Enable additional hardware on Radxa Dragon Q6A

[Graham O'Connor]

The Radxa Dragon Q6A is a compact single-board computer based on the
Qualcomm QCS6490 SoC (sc7280 family). A basic DTS for this board
already exists in mainline. This series enables the remaining hardware
and fixes platform-specific issues required for correct operation when
booting via UEFI firmware.

Patches 1-3 fix platform issues affecting QCS6490 boards booting via
UEFI firmware:

- The RSC hardware solver is left active by the UEFI firmware, causing
  a security violation if the kernel attempts to reinitialize it.
- EFI variable access requires the board compatible string in the SCM
  allowlist.
- The RA620 DP-to-HDMI bridge does not complete link training at
  voltage swing level 3. Capping at level 2 matches the vendor kernel
  behaviour and allows HDMI output to work correctly.

Patches 4-6 add DTS nodes enabling:

- GPU (Adreno 643) with clock controller and GMU
- DisplayPort output via RA620 passive DP-to-HDMI bridge
- USB3 SuperSpeed via the QMP combo PHY shared with DisplayPort

The following has been confirmed working on this board with mainline
drivers:
- KDE Plasma 6.6.5 desktop on Wayland with GPU acceleration
- HDMI display output via RA620 passive DP-to-HDMI bridge
- USB3 SuperSpeed (5Gbps confirmed via lsusb)
- OpenGL 4.6 and Vulkan 1.3 via Mesa Freedreno/Turnip
- Hardware video decode/encode via Venus (H.264, HEVC, VP9, MPEG-2)
- Audio via WCD938x codec (headphone output, microphone, HDMI audio)
- FastRPC interface to Hexagon DSP available (/dev/fastrpc-cdsp)
  though inference workloads have not been tested

With the out-of-tree AIC8800 driver for the onboard Quectel FCU760K
WiFi/BT module, all remaining hardware on the board is functional
under mainline Linux.

Tested on Radxa Dragon Q6A (QCS6490) with mainline Linux 7.0.9.



Graham O'Connor (6):
  soc: qcom: rpmh-rsc: Skip TCS init when RSC is managed by firmware
  firmware: qcom: scm: Allow EFI variable access on Radxa Dragon Q6A
  drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge
  arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Add regulator supplies and
    disable EUD
  arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable GPU and display
    pipeline
  arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB3 SuperSpeed

 .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 176 ++++++++++++++++++
 drivers/firmware/qcom/qcom_scm.c              |   1 +
 drivers/gpu/drm/msm/dp/dp_link.h              |   2 +-
 drivers/soc/qcom/rpmh-rsc.c                   |  14 ++
 4 files changed, 192 insertions(+), 1 deletion(-)

-- 
2.53.0

[PATCH 1/6] soc: qcom: rpmh-rsc: Skip TCS init when RSC is managed by firmware

[Graham O'Connor]

On QCS6490-based platforms booting via UEFI, the RSC hardware solver
is already active when the kernel takes over from the firmware. Calling
rpmh_probe_tcs_config() in this state reinitializes the controller
while the firmware is actively managing it, causing a security
violation and system reset.

Check whether the hardware solver is already enabled via the
DRV_SOLVER_CONFIG register before calling rpmh_probe_tcs_config().
If the solver is active, skip TCS initialization and return early
after setting the driver data, allowing other drivers to find the
controller without disrupting the firmware-managed state.

Tested on Radxa Dragon Q6A (QCS6490)

Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
---
 drivers/soc/qcom/rpmh-rsc.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index c6f7d5c9c..7915f12de 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -1074,6 +1074,20 @@ static int rpmh_rsc_probe(struct platform_device *pdev)
 	else
 		drv->regs = rpmh_rsc_reg_offset_ver_2_7;
 
+	/*
+	 * On some platforms the RSC is already managed by the firmware
+	 * when the kernel boots. Calling rpmh_probe_tcs_config() in this
+	 * state would reinitialize the controller and cause a security
+	 * violation. Skip TCS initialization if the hardware solver is
+	 * already active.
+	 */
+	if (readl_relaxed(drv->base + drv->regs[DRV_SOLVER_CONFIG]) &
+	    (DRV_HW_SOLVER_MASK << DRV_HW_SOLVER_SHIFT)) {
+		dev_dbg(&pdev->dev, "RSC already managed by firmware, skipping TCS init\n");
+		platform_set_drvdata(pdev, drv);
+		return 0;
+	}
+
 	ret = rpmh_probe_tcs_config(pdev, drv);
 	if (ret)
 		return ret;
-- 
2.53.0

[PATCH 2/6] firmware: qcom: scm: Allow EFI variable access on Radxa Dragon Q6A

[Graham O'Connor]

Add the Radxa Dragon Q6A compatible string to the SCM allowlist to
enable EFI variable access on this platform. Without this entry,
the SCM driver refuses to service EFI variable requests, preventing
the system from reading and writing UEFI variables.

Tested on Radxa Dragon Q6A (QCS6490)

Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
---
 drivers/firmware/qcom/qcom_scm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 6b601a4b8..4702ad898 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2320,6 +2320,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "qcom,x1e80100-crd" },
 	{ .compatible = "qcom,x1e80100-qcp" },
 	{ .compatible = "qcom,x1p42100-crd" },
+	{ .compatible = "radxa,dragon-q6a" },
 	{ }
 };
 
-- 
2.53.0

[PATCH 3/6] drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge

[Graham O'Connor]

The RA620 DP-to-HDMI bridge used on the Radxa Dragon Q6A does not
acknowledge DP link training at voltage swing level 3. The bridge
requests maximum voltage swing but never completes link training
when the driver attempts level 3, causing HDMI output to fail.

Cap DP_TRAIN_LEVEL_MAX at 2 to match the behaviour of the vendor
kernel, where link training completes successfully at level 2.
This allows the RA620 bridge to establish a stable HDMI connection.

Tested on Radxa Dragon Q6A (QCS6490) with RA620 DP-to-HDMI bridge

Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
---
 drivers/gpu/drm/msm/dp/dp_link.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_link.h b/drivers/gpu/drm/msm/dp/dp_link.h
index 76125e9c0..ff0d8e99d 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.h
+++ b/drivers/gpu/drm/msm/dp/dp_link.h
@@ -24,7 +24,7 @@ struct msm_dp_link_info {
 	unsigned long capabilities;
 };
 
-#define DP_TRAIN_LEVEL_MAX	3
+#define DP_TRAIN_LEVEL_MAX	2
 
 struct msm_dp_link_test_video {
 	u32 test_video_pattern;
-- 
2.53.0

[PATCH 4/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Add regulator supplies and disable EUD

[Graham O'Connor]

Add missing regulator supplies for qfprom and the PCIe controllers.
The qfprom node requires vcc-supply for correct eFuse reading. The
PCIe controllers require vdda and vddpe-3v3 supplies for the PHY and
connector power rails.

Disable the Embedded USB Debugger (EUD) as it conflicts with normal
USB operation on this board.

Tested on Radxa Dragon Q6A (QCS6490)

Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
---
 .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
index bb5a42b03..4003837ad 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -1093,3 +1093,23 @@ &sdc2_data {
 	bias-pull-up;
 	drive-strength = <10>;
 };
+
+/* Provide required regulator supplies for qfprom and PCIe controllers */
+&qfprom {
+	vcc-supply = <&vreg_l1c_1p8>;
+};
+
+&pcie0 {
+	vdda-supply = <&vreg_l1c_1p8>;
+	vddpe-3v3-supply = <&vreg_bob_3p296>;
+};
+
+&pcie1 {
+	vdda-supply = <&vreg_l1c_1p8>;
+	vddpe-3v3-supply = <&vreg_bob_3p296>;
+};
+
+/* Disable EUD as it conflicts with USB operation */
+&eud {
+	status = "disabled";
+};
-- 
2.53.0

[PATCH 5/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable GPU and display pipeline

[Graham O'Connor]

Enable the GPU clock controller (gpucc), GMU, display clock controller
(dispcc), and MDSS display subsystem.

Add DisplayPort HPD pinctrl state for GPIO47 and wire up the DP output
pipeline through the RA620 DP-to-HDMI bridge. The RA620 is a passive
hardware bridge requiring no driver - it converts DP to HDMI
autonomously. Add the dp-connector and hdmi-connector nodes to complete
the display graph.

Disable DSI, DSI PHY, eDP, and eDP PHY as these interfaces are not
present on the Radxa Dragon Q6A hardware.

Tested on Radxa Dragon Q6A (QCS6490) with RA620 DP-to-HDMI bridge
connected to an HDMI monitor.

Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
---
 .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 85 +++++++++++++++++++
 1 file changed, 85 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
index 4003837ad..e8ad6e666 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -1113,3 +1113,88 @@ &pcie1 {
 &eud {
 	status = "disabled";
 };
+
+&gpucc {
+	status = "okay";
+};
+
+&gmu {
+	status = "okay";
+};
+
+&dispcc {
+	status = "okay";
+};
+
+&mdss {
+	status = "okay";
+};
+
+&tlmm {
+	dp_hot_plug_det: dp-hot-plug-det-state {
+		pins = "gpio47";
+		function = "dp_hot";
+		bias-disable;
+	};
+};
+
+/ {
+	hdmi-bridge {
+		compatible = "dp-connector";
+		label = "hdmi";
+		type = "full-size";
+		pinctrl-names = "default";
+		pinctrl-0 = <&dp_hot_plug_det>;
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			port@0 {
+				reg = <0>;
+				hdmi_bridge_in: endpoint {
+					remote-endpoint = <&usb_dp_qmpphy_out_dp>;
+				};
+			};
+			port@1 {
+				reg = <1>;
+				hdmi_bridge_out: endpoint {
+					remote-endpoint = <&hdmi_connector_in>;
+				};
+			};
+		};
+	};
+
+	hdmi-connector {
+		compatible = "hdmi-connector";
+		label = "hdmi";
+		type = "a";
+		port {
+			hdmi_connector_in: endpoint {
+				remote-endpoint = <&hdmi_bridge_out>;
+			};
+		};
+	};
+};
+
+&mdss_dp {
+	status = "okay";
+};
+
+&mdss_dp_out {
+	data-lanes = <0 1>;
+};
+
+&mdss_dsi {
+	status = "disabled";
+};
+
+&mdss_dsi_phy {
+	status = "disabled";
+};
+
+&mdss_edp {
+	status = "disabled";
+};
+
+&mdss_edp_phy {
+	status = "disabled";
+};
-- 
2.53.0

[PATCH 6/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB3 SuperSpeed

[Graham O'Connor]

Enable the USB3-A port by configuring the USB HSPHY with required
regulator supplies and the QMP combo PHY with correct lane assignments
for this fixed USB-A connector.

The QMP combo PHY shares lanes between DisplayPort and USB3 SuperSpeed.
Configure port@0 with two endpoints: endpoint@0 for DP output (lanes
0-1) connected to the HDMI bridge, and endpoint@1 for USB3 SS output
(lanes 2-3). Remove the orientation-switch property as this is a fixed
USB-A connector with no orientation switching.

Add a usb-a-connector node wiring the HS and SS paths to the DWC3
controller and QMP PHY respectively. Set dr_mode to host as this is
a fixed host-only USB-A port.

Tested on Radxa Dragon Q6A (QCS6490) with USB3 SuperSpeed confirmed
via lsusb showing 5000M link speed.

Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
---
 .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 71 +++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
index e8ad6e666..c16c3664e 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
@@ -1198,3 +1198,74 @@ &mdss_edp {
 &mdss_edp_phy {
 	status = "disabled";
 };
+
+&usb_1_hsphy {
+	vdda-pll-supply = <&vreg_l10c_0p88>;
+	vdda18-supply = <&vreg_l1c_1p8>;
+	vdda33-supply = <&vreg_l2b_3p072>;
+	status = "okay";
+};
+
+&usb_1_qmpphy {
+	vdda-phy-supply = <&vreg_l6b_1p2>;
+	vdda-pll-supply = <&vreg_l1b_0p912>;
+	/delete-property/ orientation-switch;
+	status = "okay";
+
+	ports {
+		port@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			/delete-node/ endpoint;
+
+			/* DP output - connected to hdmi-bridge */
+			usb_dp_qmpphy_out_dp: endpoint@0 {
+				reg = <0>;
+				data-lanes = <0 1>;
+				remote-endpoint = <&hdmi_bridge_in>;
+			};
+
+			/* USB3 SS output */
+			usb_dp_qmpphy_out_usb: endpoint@1 {
+				reg = <1>;
+				data-lanes = <2 3>;
+				remote-endpoint = <&usb3_con_ss_in>;
+			};
+		};
+	};
+};
+
+/ {
+	usb3_con: connector {
+		compatible = "usb-a-connector";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				usb3_con_hs_in: endpoint {
+					remote-endpoint = <&usb_1_dwc3_hs>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				usb3_con_ss_in: endpoint {
+					remote-endpoint = <&usb_dp_qmpphy_out_usb>;
+				};
+			};
+		};
+	};
+};
+
+&usb_1_dwc3_hs {
+	remote-endpoint = <&usb3_con_hs_in>;
+};
+
+&usb_1 {
+	dr_mode = "host";
+	status = "okay";
+};
-- 
2.53.0

Re: [PATCH 5/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable GPU and display pipeline

[Neil Armstrong]

Hi,

On 5/22/26 08:06, Graham O'Connor wrote:
> Enable the GPU clock controller (gpucc), GMU, display clock controller
> (dispcc), and MDSS display subsystem.
> 
> Add DisplayPort HPD pinctrl state for GPIO47 and wire up the DP output
> pipeline through the RA620 DP-to-HDMI bridge. The RA620 is a passive
> hardware bridge requiring no driver - it converts DP to HDMI
> autonomously. Add the dp-connector and hdmi-connector nodes to complete
> the display graph.
> 
> Disable DSI, DSI PHY, eDP, and eDP PHY as these interfaces are not
> present on the Radxa Dragon Q6A hardware.
> 
> Tested on Radxa Dragon Q6A (QCS6490) with RA620 DP-to-HDMI bridge
> connected to an HDMI monitor.
> 
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
>   .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 85 +++++++++++++++++++
>   1 file changed, 85 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index 4003837ad..e8ad6e666 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -1113,3 +1113,88 @@ &pcie1 {
>   &eud {
>   	status = "disabled";
>   };
> +
> +&gpucc {
> +	status = "okay";
> +};
> +
> +&gmu {
> +	status = "okay";
> +};
> +
> +&dispcc {
> +	status = "okay";
> +};
> +
> +&mdss {
> +	status = "okay";
> +};
> +
> +&tlmm {
> +	dp_hot_plug_det: dp-hot-plug-det-state {
> +		pins = "gpio47";
> +		function = "dp_hot";
> +		bias-disable;
> +	};
> +};
> +
> +/ {
> +	hdmi-bridge {
> +		compatible = "dp-connector";

This is not the right way to enable the HDMI connector.

This patch https://lore.kernel.org/all/20250914-radxa-dragon-q6a-v2-5-045f7e92b3bb@radxa.com/
is the right way by exposing the HDMI bridge and setting the right usb_1_qmpphy data lanes.

Neil

> +		label = "hdmi";
> +		type = "full-size";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&dp_hot_plug_det>;
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			port@0 {
> +				reg = <0>;
> +				hdmi_bridge_in: endpoint {
> +					remote-endpoint = <&usb_dp_qmpphy_out_dp>;
> +				};
> +			};
> +			port@1 {
> +				reg = <1>;
> +				hdmi_bridge_out: endpoint {
> +					remote-endpoint = <&hdmi_connector_in>;
> +				};
> +			};
> +		};
> +	};
> +
> +	hdmi-connector {
> +		compatible = "hdmi-connector";
> +		label = "hdmi";
> +		type = "a";
> +		port {
> +			hdmi_connector_in: endpoint {
> +				remote-endpoint = <&hdmi_bridge_out>;
> +			};
> +		};
> +	};
> +};
> +
> +&mdss_dp {
> +	status = "okay";
> +};
> +
> +&mdss_dp_out {
> +	data-lanes = <0 1>;
> +};
> +
> +&mdss_dsi {
> +	status = "disabled";
> +};
> +
> +&mdss_dsi_phy {
> +	status = "disabled";
> +};
> +
> +&mdss_edp {
> +	status = "disabled";
> +};
> +
> +&mdss_edp_phy {
> +	status = "disabled";
> +};

Re: [PATCH 6/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB3 SuperSpeed

[Neil Armstrong]

On 5/22/26 08:06, Graham O'Connor wrote:
> Enable the USB3-A port by configuring the USB HSPHY with required
> regulator supplies and the QMP combo PHY with correct lane assignments
> for this fixed USB-A connector.
> 
> The QMP combo PHY shares lanes between DisplayPort and USB3 SuperSpeed.
> Configure port@0 with two endpoints: endpoint@0 for DP output (lanes
> 0-1) connected to the HDMI bridge, and endpoint@1 for USB3 SS output
> (lanes 2-3). Remove the orientation-switch property as this is a fixed
> USB-A connector with no orientation switching.
> 
> Add a usb-a-connector node wiring the HS and SS paths to the DWC3
> controller and QMP PHY respectively. Set dr_mode to host as this is
> a fixed host-only USB-A port.
> 
> Tested on Radxa Dragon Q6A (QCS6490) with USB3 SuperSpeed confirmed
> via lsusb showing 5000M link speed.
> 
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
>   .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 71 +++++++++++++++++++
>   1 file changed, 71 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index e8ad6e666..c16c3664e 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -1198,3 +1198,74 @@ &mdss_edp {
>   &mdss_edp_phy {
>   	status = "disabled";
>   };
> +
> +&usb_1_hsphy {
> +	vdda-pll-supply = <&vreg_l10c_0p88>;
> +	vdda18-supply = <&vreg_l1c_1p8>;
> +	vdda33-supply = <&vreg_l2b_3p072>;
> +	status = "okay";
> +};
> +
> +&usb_1_qmpphy {
> +	vdda-phy-supply = <&vreg_l6b_1p2>;
> +	vdda-pll-supply = <&vreg_l1b_0p912>;
> +	/delete-property/ orientation-switch;
> +	status = "okay";
> +
> +	ports {
> +		port@0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			/delete-node/ endpoint;
> +
> +			/* DP output - connected to hdmi-bridge */
> +			usb_dp_qmpphy_out_dp: endpoint@0 {
> +				reg = <0>;
> +				data-lanes = <0 1>;
> +				remote-endpoint = <&hdmi_bridge_in>;
> +			};

Previous patch needs this change to work, please squash.

Neil

> +
> +			/* USB3 SS output */
> +			usb_dp_qmpphy_out_usb: endpoint@1 {
> +				reg = <1>;
> +				data-lanes = <2 3>;
> +				remote-endpoint = <&usb3_con_ss_in>;
> +			};
> +		};
> +	};
> +};
> +
> +/ {
> +	usb3_con: connector {
> +		compatible = "usb-a-connector";
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port@0 {
> +				reg = <0>;
> +				usb3_con_hs_in: endpoint {
> +					remote-endpoint = <&usb_1_dwc3_hs>;
> +				};
> +			};
> +
> +			port@1 {
> +				reg = <1>;
> +				usb3_con_ss_in: endpoint {
> +					remote-endpoint = <&usb_dp_qmpphy_out_usb>;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&usb_1_dwc3_hs {
> +	remote-endpoint = <&usb3_con_hs_in>;
> +};
> +
> +&usb_1 {
> +	dr_mode = "host";
> +	status = "okay";
> +};

Re: [PATCH 3/6] drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge

[Konrad Dybcio]

On 5/22/26 8:06 AM, Graham O'Connor wrote:
> The RA620 DP-to-HDMI bridge used on the Radxa Dragon Q6A does not
> acknowledge DP link training at voltage swing level 3. The bridge
> requests maximum voltage swing but never completes link training
> when the driver attempts level 3, causing HDMI output to fail.
> 
> Cap DP_TRAIN_LEVEL_MAX at 2 to match the behaviour of the vendor
> kernel, where link training completes successfully at level 2.
> This allows the RA620 bridge to establish a stable HDMI connection.
> 
> Tested on Radxa Dragon Q6A (QCS6490) with RA620 DP-to-HDMI bridge
> 
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
>  drivers/gpu/drm/msm/dp/dp_link.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/dp/dp_link.h b/drivers/gpu/drm/msm/dp/dp_link.h
> index 76125e9c0..ff0d8e99d 100644
> --- a/drivers/gpu/drm/msm/dp/dp_link.h
> +++ b/drivers/gpu/drm/msm/dp/dp_link.h
> @@ -24,7 +24,7 @@ struct msm_dp_link_info {
>  	unsigned long capabilities;
>  };
>  
> -#define DP_TRAIN_LEVEL_MAX	3
> +#define DP_TRAIN_LEVEL_MAX	2

You're limiting this value for *all* devices featuring a Qualcomm
SoC with a DP controller. Instead, if this is really an issue that
results from the bridge's capabilities (which could potentially only
be a symptom, not the cause), this should be somehow limited to the
specific bridge itself

Konrad

Re: [PATCH 0/6] arm64: qcom: Enable additional hardware on Radxa Dragon Q6A

[Graham O'Connor]

Thank you to Konrad, Neil, and others for the very prompt and helpful reviews.

Based on the feedback received, I think it best to withdraw this series to
address the issues raised, most notobly:

1. The DP_TRAIN_LEVEL_MAX change (patch 3) is too broad - it affects all
   devices using the Qualcomm MSM DP driver rather than being specific to
   the RA620 bridge. A proper fix should be implemented at the bridge
   level. This is going to take more investigation.

2. The display DT nodes (patch 5) should use the radxa,ra620 compatible
   string per the existing Radxa upstream series from Xilin Wu, and the
   lane ordering needs correcting.

3. The rpmh-rsc early return (patch 1) needs further review regarding
   the implications of returning before full driver initialization.

4. DTS patch label dependency issue (sorry) 

I'll integrate with the Radxa upstream effort, re-evaluate the other areas
and resubmit corrected patches addressing these concerns at a later date.

Thanks for the feedback.

Cheers

Graham

Re: [PATCH 0/6] arm64: qcom: Enable additional hardware on Radxa Dragon Q6A

[Xilin Wu]

On 5/22/2026 6:13 PM, Graham O'Connor wrote:
> Thank you to Konrad, Neil, and others for the very prompt and helpful reviews.
> 
> Based on the feedback received, I think it best to withdraw this series to
> address the issues raised, most notobly:
> 
> 1. The DP_TRAIN_LEVEL_MAX change (patch 3) is too broad - it affects all
>     devices using the Qualcomm MSM DP driver rather than being specific to
>     the RA620 bridge. A proper fix should be implemented at the bridge
>     level. This is going to take more investigation.
> 
> 2. The display DT nodes (patch 5) should use the radxa,ra620 compatible
>     string per the existing Radxa upstream series from Xilin Wu, and the
>     lane ordering needs correcting.
> 
> 3. The rpmh-rsc early return (patch 1) needs further review regarding
>     the implications of returning before full driver initialization.
> 
> 4. DTS patch label dependency issue (sorry)
> 
> I'll integrate with the Radxa upstream effort, re-evaluate the other areas
> and resubmit corrected patches addressing these concerns at a later date.
> 
> Thanks for the feedback.
> 
> Cheers
> 
> Graham

Hi Graham,

Thanks for working on the additional hardware bring-up for Q6A upstream 
support. I'm really glad to see someone pushing this forward.

I actually posted a patch series [1] last month, and it is generally in 
good shape. Unfortunately, I got busy with other work and haven't had a 
chance to send v2 yet.

If it helps, please feel free to take over that series and fold your 
additional patches into it. I think that would be a good way to move 
things forward.

Also, I believe patches 10-12 in my series are no longer needed and can 
be dropped.

Thank you again for the work you have done.

[1] 
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=1078242&state=%2A&archive=both

-- 
Best regards,
Xilin Wu <sophon@radxa.com>

Re: [PATCH 2/6] firmware: qcom: scm: Allow EFI variable access on Radxa Dragon Q6A

[Dmitry Baryshkov]

On Fri, May 22, 2026 at 06:06:41PM +1200, Graham O'Connor wrote:
> Add the Radxa Dragon Q6A compatible string to the SCM allowlist to
> enable EFI variable access on this platform. Without this entry,
> the SCM driver refuses to service EFI variable requests, preventing
> the system from reading and writing UEFI variables.

Which medium is used by Q6A to store UEFI vars?

> 
> Tested on Radxa Dragon Q6A (QCS6490)
> 
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 6b601a4b8..4702ad898 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2320,6 +2320,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
>  	{ .compatible = "qcom,x1e80100-crd" },
>  	{ .compatible = "qcom,x1e80100-qcp" },
>  	{ .compatible = "qcom,x1p42100-crd" },
> +	{ .compatible = "radxa,dragon-q6a" },
>  	{ }
>  };
>  
> -- 
> 2.53.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH 4/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Add regulator supplies and disable EUD

[Dmitry Baryshkov]

On Fri, May 22, 2026 at 06:06:43PM +1200, Graham O'Connor wrote:
> Add missing regulator supplies for qfprom and the PCIe controllers.
> The qfprom node requires vcc-supply for correct eFuse reading. The
> PCIe controllers require vdda and vddpe-3v3 supplies for the PHY and
> connector power rails.

vddpe-3v3 is a legacy property for specifying power rails for connected
devices rather than the controller.

> 
> Disable the Embedded USB Debugger (EUD) as it conflicts with normal
> USB operation on this board.

Separate commot please, with the description of the conflict.

> 
> Tested on Radxa Dragon Q6A (QCS6490)
> 
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
>  .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 20 +++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index bb5a42b03..4003837ad 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -1093,3 +1093,23 @@ &sdc2_data {
>  	bias-pull-up;
>  	drive-strength = <10>;
>  };
> +
> +/* Provide required regulator supplies for qfprom and PCIe controllers */
> +&qfprom {
> +	vcc-supply = <&vreg_l1c_1p8>;
> +};

Please keep the nodes sorted.

> +
> +&pcie0 {
> +	vdda-supply = <&vreg_l1c_1p8>;
> +	vddpe-3v3-supply = <&vreg_bob_3p296>;
> +};
> +
> +&pcie1 {
> +	vdda-supply = <&vreg_l1c_1p8>;
> +	vddpe-3v3-supply = <&vreg_bob_3p296>;
> +};
> +
> +/* Disable EUD as it conflicts with USB operation */
> +&eud {
> +	status = "disabled";
> +};
> -- 
> 2.53.0
> 

-- 
With best wishes
Dmitry

Claude review: arm64: qcom: Enable additional hardware on Radxa Dragon Q6A

[Claude Code Review Bot]

Overall Series Review

Subject: arm64: qcom: Enable additional hardware on Radxa Dragon Q6A
Author: Graham O'Connor <graham.oconnor@gmail.com>
Patches: 14
Reviewed: 2026-05-25T19:16:36.146330

---

This is a 6-patch series enabling additional hardware on the Radxa Dragon Q6A (QCS6490) when booting via UEFI. The series covers RSC firmware coexistence, EFI variable access, DP link training, and DTS additions for GPU/display/USB3.

The DTS patches (4-6) are generally well-structured and demonstrate real hardware testing. However, there are two significant issues:

1. **Patch 3 (DP_TRAIN_LEVEL_MAX)** changes a global constant affecting *all* MSM DP connections, not just the RA620 bridge. This will regress other platforms that require voltage swing level 3. This needs to be reworked as a per-bridge or per-platform quirk.

2. **Patch 1 (rpmh-rsc)** early-returns from probe, skipping critical initialization including `devm_of_platform_populate()`, IRQ setup, and client cache initialization. Child devices won't probe, and the `rsc_drv` structure left in driver data is only partially initialized, risking use of uninitialized fields if any code later references it.

The DTS display pipeline modeling in patch 5 uses `dp-connector` to represent what is described as a bridge, which is semantically questionable and misuses port@1 of the binding.

---

---
Generated by Claude Code Patch Reviewer

Claude review: soc: qcom: rpmh-rsc: Skip TCS init when RSC is managed by firmware

[Claude Code Review Bot]

Patch Review

**Concept**: When UEFI firmware leaves the RSC hardware solver active, skip TCS reinitialization to avoid a security violation.

**Issue 1 — Too much is skipped.** Looking at the normal probe path in `rpmh_rsc_probe()` (rpmh-rsc.c:1077-1131), the early return skips:
- `rpmh_probe_tcs_config()` (intended)
- Spinlock/waitqueue/bitmap initialization
- IRQ registration
- Active TCS interrupt enable
- Client cache list initialization
- **`devm_of_platform_populate()`** — child nodes (rpmh clients) will never probe

```c
+	if (readl_relaxed(drv->base + drv->regs[DRV_SOLVER_CONFIG]) &
+	    (DRV_HW_SOLVER_MASK << DRV_HW_SOLVER_SHIFT)) {
+		dev_dbg(&pdev->dev, "RSC already managed by firmware, skipping TCS init\n");
+		platform_set_drvdata(pdev, drv);
+		return 0;
+	}
```

The `drv` set as driver data has uninitialized `lock`, `tcs_wait`, `tcs_in_use`, `client.cache`, and `client.batch_cache`. If any consumer obtains this `drv` pointer and attempts an rpmh operation, it will operate on uninitialized data.

**Issue 2 — No `devm_of_platform_populate()`.** The commit message says "allowing other drivers to find the controller," but child platform devices of the RSC node won't be created without this call. Is the intent that the entire RSC subsystem should be inert on this platform? If so, the commit message should explain that. If children should still probe, then at minimum `devm_of_platform_populate()` needs to be called in the early-return path.

**Issue 3 — dev_dbg vs dev_info.** Silently skipping the entire RSC init path is a significant behavioral change. Using `dev_info` or `dev_notice` would help debug boot issues.

**Suggestion**: If the firmware-managed case truly means the kernel should not interact with this RSC at all, consider whether probing should succeed at all, or whether the driver should explicitly populate children while leaving TCS alone. The current approach creates a half-initialized driver data structure.

---

---
Generated by Claude Code Patch Reviewer

Claude review: firmware: qcom: scm: Allow EFI variable access on Radxa Dragon Q6A

[Claude Code Review Bot]

Patch Review

This patch adds `"radxa,dragon-q6a"` to the QSEECOM allowlist.

```c
+	{ .compatible = "radxa,dragon-q6a" },
```

**No issues.** The allowlist already contains many vendor-prefixed entries (asus, dell, hp, lenovo, microsoft, etc.), so a `radxa,` entry follows the established pattern. The placement after the last `qcom,` entry maintains alphabetical ordering by vendor prefix.

One minor note: this allowlist is a security-relevant gate for EFI variable access. Maintainers may want to verify that QSEECOM is functional and safe on this platform beyond just "it works."

---

---
Generated by Claude Code Patch Reviewer

Claude review: Re: [PATCH 3/6] drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge

[Claude Code Review Bot]

Patch Review

**This patch has a serious problem: it changes a global constant.**

```c
-#define DP_TRAIN_LEVEL_MAX	3
+#define DP_TRAIN_LEVEL_MAX	2
```

`DP_TRAIN_LEVEL_MAX` is used throughout the MSM DP driver for *all* DP connections:

- `dp_ctrl.c`: Determines when `DP_TRAIN_MAX_SWING_REACHED` is signaled to the sink
- `dp_link.c`: Clamps voltage swing and pre-emphasis levels; calculates `max_p_level = DP_TRAIN_LEVEL_MAX - v_level`

The DP specification defines voltage swing levels 0-3. Level 3 (1200 mV) is a valid, in-spec operating point. Some monitors and bridges legitimately require level 3 to establish a link. Capping the global maximum at 2 will break those configurations on all Qualcomm DP platforms — not just the Radxa Dragon Q6A.

**Recommendation**: This needs to be a per-bridge or per-platform quirk, not a global constant change. Options include:
1. A device tree property on the DP node specifying the max voltage swing level
2. A quirk based on the connected bridge's identity (though the RA620 is passive and has no identity)
3. A platform-specific override in the board DTS that the DP driver reads

The commit message correctly identifies the problem (RA620 doesn't complete link training at level 3) but the fix has too broad a blast radius.

---

---
Generated by Claude Code Patch Reviewer

Claude review: arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Add regulator supplies and disable EUD

[Claude Code Review Bot]

Patch Review

```dts
+&qfprom {
+	vcc-supply = <&vreg_l1c_1p8>;
+};
+
+&pcie0 {
+	vdda-supply = <&vreg_l1c_1p8>;
+	vddpe-3v3-supply = <&vreg_bob_3p296>;
+};
+
+&pcie1 {
+	vdda-supply = <&vreg_l1c_1p8>;
+	vddpe-3v3-supply = <&vreg_bob_3p296>;
+};
+
+&eud {
+	status = "disabled";
+};
```

**No significant issues.** This is straightforward DTS plumbing. The `vreg_bob_3p296` for `vddpe-3v3` is within tolerance for a nominal 3.3V rail (BOB regulators commonly produce slightly non-standard voltages). Disabling EUD for normal USB operation is standard practice.

Minor: the commit message bundles two conceptually separate changes (regulator supplies + EUD disable). These could be separate patches for cleaner bisection, but it's not a hard requirement.

---

---
Generated by Claude Code Patch Reviewer

Claude review: Re: [PATCH 5/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable GPU and display pipeline

[Claude Code Review Bot]

Patch Review

**Issue 1 — `dp-connector` used as a bridge.** The `hdmi-bridge` node uses `compatible = "dp-connector"`:

```dts
+	hdmi-bridge {
+		compatible = "dp-connector";
+		label = "hdmi";
+		type = "full-size";
```

The `dp-connector` binding (Documentation/devicetree/bindings/display/connector/dp-connector.yaml) represents a *physical DP connector* — the port where you plug in a DP cable. The RA620 is not a DP connector; it's a DP-to-HDMI bridge. Using `dp-connector` to model a bridge is semantically incorrect.

Furthermore, the `dp-connector` binding defines port@1 as "Connection to controller providing AUX signals." This patch uses port@1 as an output to the HDMI connector, which doesn't match the binding:

```dts
+			port@1 {
+				reg = <1>;
+				hdmi_bridge_out: endpoint {
+					remote-endpoint = <&hdmi_connector_in>;
+				};
+			};
```

**Issue 2 — Naming confusion.** The node is called `hdmi-bridge` but uses `dp-connector` compatible. The label is "hdmi" but it's a DP endpoint. This will confuse future readers.

**Issue 3 — pinctrl on "connector" node.** The `dp_hot_plug_det` pinctrl is attached to the `hdmi-bridge` (dp-connector) node. HPD pinctrl would more typically belong on the DP controller node (`&mdss_dp`).

The GPU enable parts (`gpucc`, `gmu`, `dispcc`, `mdss` status = "okay") and the disabling of DSI/eDP interfaces are all fine.

---

---
Generated by Claude Code Patch Reviewer

Claude review: Re: [PATCH 6/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB3 SuperSpeed

[Claude Code Review Bot]

Patch Review

```dts
+&usb_1_qmpphy {
+	vdda-phy-supply = <&vreg_l6b_1p2>;
+	vdda-pll-supply = <&vreg_l1b_0p912>;
+	/delete-property/ orientation-switch;
+	status = "okay";
```

**Generally looks correct.** The use of `/delete-property/ orientation-switch` is appropriate since this is a fixed USB-A connector (no orientation detection needed). The lane assignment with DP on lanes 0-1 and USB3 SS on lanes 2-3 follows the standard QMP combo PHY split.

```dts
+	usb3_con: connector {
+		compatible = "usb-a-connector";
```

The USB-A connector node with dual-port (HS + SS) configuration is properly structured.

**Minor**: The `&usb_1` node sets `dr_mode = "host"` but doesn't set `status = "okay"` for the DWC3 child. If the base DTS has the DWC3 disabled, USB won't work. However, this depends on the base DTS defaults which may already have it enabled.

**Minor**: The `&usb_1_dwc3_hs` endpoint override is placed between the connector block and the `&usb_1` block, which works but reads slightly disjointed.

---
Generated by Claude Code Patch Reviewer