[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Returning early from the probe function bypasses the initialization of critical locks, waitqueues, and list heads, leading to kernel panics when RPMh APIs are invoked.
- [High] The early return completely skips `devm_of_platform_populate()`, preventing essential child devices from probing and permanently breaking the system boot process.
--

commit 42c9f85b1ee98ffd687b17f97edf46cb0e222ced
Author: Graham O'Connor <graham.oconnor@gmail.com>

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

This commit skips TCS initialization in the RPMh RSC driver when the hardware
solver is already active. This prevents security violations and system resets
caused by reinitializing a controller that is actively managed by firmware.

> --- 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;

[Severity: Critical]
Since drv is allocated with devm_kzalloc(), bypassing the rest of the probe
function leaves essential software structures uninitialized.

Specifically, spin_lock_init(&drv->client.cache_lock),
init_waitqueue_head(&drv->tcs_wait), and INIT_LIST_HEAD(&drv->client.cache)
are skipped.

Because platform_set_drvdata(pdev, drv) exposes this controller to other
drivers, will standard RPMh APIs like rpmh_write() crash with a NULL pointer
dereference when attempting to acquire the uninitialized spinlock or add to
the zero-initialized list head?

[Severity: High]
Does this early return also skip the instantiation of child devices?

The rpmh_rsc_probe() function normally relies on devm_of_platform_populate()
at the end of the function to instantiate its children. By returning early,
crucial child devices such as the clock controller (rpmhcc), power domain
controller (rpmhpd), and interconnect voters (bcm-voter) are never created.

Will this leave downstream peripheral drivers that depend on these clocks
or regulators permanently stuck in an -EPROBE_DEFER state, breaking the
system boot process?

> +	}
> +
>  	ret = rpmh_probe_tcs_config(pdev, drv);
>  	if (ret)
>  		return ret;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522060645.4399-1-graham.oconnor@gmail.com?part=1

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] A device-specific workaround for the RA620 bridge is applied globally, capping the maximum voltage swing and pre-emphasis levels for all DP devices using the MSM DP driver.
--

commit cfc03fd78122eb643ca94e4cccdc197ffa9a8de0
Author: Graham O'Connor <graham.oconnor@gmail.com>

drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge

This commit reduces the maximum DisplayPort link training level to 2 to work
around a link training failure specific to the RA620 DP-to-HDMI bridge used
on the Radxa Dragon Q6A platform.

> diff --git a/drivers/gpu/drm/msm/dp/dp_link.h b/drivers/gpu/drm/msm/dp/dp_link.h
> index 76125e9c07e9c..ff0d8e99d87c9 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

[Severity: High]
Does this change globally cap the maximum voltage swing and pre-emphasis
levels for all DisplayPort devices using the MSM DP driver?

Because the DP specification supports voltage swing up to level 3, which is
often required for signal integrity over long cables or at high bandwidths,
removing this capability globally can cause link training failures and
unstable connections on fully compliant displays.

Furthermore, since maximum pre-emphasis is calculated as DP_TRAIN_LEVEL_MAX
minus the voltage level, capping this macro at 2 means that if a voltage
swing level of 2 is used, the pre-emphasis level is strictly constrained to 0.

Could this hardware-specific workaround for the RA620 bridge be implemented
conditionally (for example, via DPCD OUI detection, bridge properties, or
device tree matching) rather than permanently degrading global subsystem
capabilities for all platforms?

>  
>  struct msm_dp_link_test_video {
>  	u32 test_video_pattern;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522060645.4399-1-graham.oconnor@gmail.com?part=3

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

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Adding the undocumented 'vdda-supply' property to the PCIe controller nodes breaks Device Tree schema validation.
--

commit 6e4637b222af4746ef1edd2421be8601e301a29c
Author: Graham O'Connor <graham.oconnor@gmail.com>

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

This commit adds missing regulator supplies for the qfprom and PCIe
controllers on the Radxa Dragon Q6A board. It also disables the Embedded USB
Debugger (EUD) due to conflicts with normal USB operation.

> 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 bb5a42b038f19..4003837ad5756 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts

[ ... ]

> +&pcie0 {
> +	vdda-supply = <&vreg_l1c_1p8>;

[Severity: Low]
Does adding this property cause a dtbs_check schema validation error?

The device tree binding schema for this compatible (qcom,pcie-sc7280.yaml
and its included qcom,pcie-common.yaml) enforces unevaluatedProperties: false
and does not appear to define a vdda-supply property.

While the PCIe driver (pcie-qcom.c) attempts to request a vdda regulator,
adding undocumented properties directly to the device tree will cause
validation to fail.

> +	vddpe-3v3-supply = <&vreg_bob_3p296>;
> +};
> +
> +&pcie1 {
> +	vdda-supply = <&vreg_l1c_1p8>;

[Severity: Low]
This has the same schema validation issue as the pcie0 node above.

> +	vddpe-3v3-supply = <&vreg_bob_3p296>;
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522060645.4399-1-graham.oconnor@gmail.com?part=4

[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

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 5/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable GPU and display pipeline

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `hdmi-bridge` node misuses the `dp-connector` compatible string, violating device tree schemas and breaking the DRM bridge chain.
- [High] The device tree references an undefined label `usb_dp_qmpphy_out_dp` and defines a unidirectional OF graph connection, causing a DTC compilation failure.
- [Medium] The DP HPD pinctrl state is incorrectly assigned to the passive bridge node instead of the SoC's active DP controller node.
--

commit 92168a3bddd844517ae0cec7b663112085ad6837
Author: Graham O'Connor <graham.oconnor@gmail.com>

arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable GPU and display pipeline

Enable the GPU, GMU, dispcc, and MDSS subsystems, and wire up the DisplayPort
output pipeline through a passive RA620 DP-to-HDMI bridge. Disable unused
DSI and eDP interfaces.

> 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 4003837ad5756..e8ad6e666f5fd 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts

[ ... ]

> +/ {
> +	hdmi-bridge {
> +		compatible = "dp-connector";

[Severity: High]
Does using the dp-connector compatible string here break the DRM bridge
chain?

The dp-connector binding designates port@1 exclusively for AUX signals, not
downstream video bridging. The Linux display-connector DRM driver acts as a
terminal endpoint and only parses port@0 for its upstream connection, never
searching for a downstream bridge.

Because of this, it looks like the DRM pipeline will terminate prematurely at
the hdmi-bridge, exposing a DisplayPort connector to userspace instead of an
HDMI connector, and leaving the hdmi-connector node completely orphaned.

Should this use compatible = "radxa,ra620" instead, which the simple-bridge
driver supports for bridging video to an output port?

> +		label = "hdmi";
> +		type = "full-size";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&dp_hot_plug_det>;

[Severity: Medium]
Should this pinctrl state be requested by the &mdss_dp node instead of the
passive bridge node?

The dp_hot_plug_det configuration sets GPIO47 to the dp_hot alternate
function, which natively routes the physical hardware signal directly to the
SoC's DP controller block (mdss_dp).

Tying the SoC's hardware pin multiplexing to a downstream connector seems to
bypass the DP driver's ability to correctly manage the pin's state during
suspend and resume cycles.

> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			port@0 {
> +				reg = <0>;
> +				hdmi_bridge_in: endpoint {
> +					remote-endpoint = <&usb_dp_qmpphy_out_dp>;

[Severity: High]
Does referencing the &usb_dp_qmpphy_out_dp label here cause a dtc compilation
failure?

The label usb_dp_qmpphy_out_dp does not appear to be defined anywhere in the
included device trees at this commit, which will cause dtc to fail with an
undefined reference error. Furthermore, the reverse link from the PHY's
output endpoint back to the bridge's input is missing.

While this build regression is fixed later in the patch series by commit
"arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB3 SuperSpeed", each
individual patch in a series must compile to maintain bisectability.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522060645.4399-1-graham.oconnor@gmail.com?part=5

[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 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 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