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

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

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

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

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

[Konrad Dybcio]

On 5/22/26 8:06 AM, Graham O'Connor wrote:
> 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.

I don't think this has been an issue so far on other platforms..

Do you have some more details?

Konrad

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

[Gekko]

Hi Konrad,

This one is confusing.

I started the bring-up on this board on gentoo-sources 6.18.18 but the 
board would not boot. After an almost subliminal flash of tux the board 
would lock every time.I found the solution from PostmarketOS who 
obviously faced the same issue which formed the genesis of this patch. 
With this patch applied the board booted fine so I've applied it ever since.

However, as a result of your response here I tried booting my current 
kernel (gentoo-sources 7.0.10) without the patch and to my surprise it 
booted just fine. This leaves a few options, including:
1) the kernel source has changed
2) this is a firmware issue and a firmware update fixed it
3) It's a timing issue.

To eliminate 2 I would have to test 6.18.18 with the current firmware, 
then regress the firmware and test again. The do the same with 7.0.10. I 
can't honestly recall whether the firmware upgrade was before or after 
this issue first appeared.

If it's a timing issue it's a bit more concerning. If the kernel is 
taking slightly longer to initialise before calling 
rpmh_probe_tcs_config() then it may just be missing the solver 
activation, everything appears to work and nobody is any the wiser. If 
the existing solver code doesn't deal with early firmware TCS 
initialisation then it could, under some circumstances, lead to the 
security reset that I was seeing. This patch specifically tests for that 
case.

Based on the AI review feedback I've also modified the patch to not 
simply return early but to just skip the sensitive parts of the code to 
allow any other setup to complete normally.

My current objective evidence is that the board boots without this patch 
and it's quite possible this patch is unnecessary if the above is incorrect.

Graham


On 26/05/2026 00:40, Konrad Dybcio wrote:
> On 5/22/26 8:06 AM, Graham O'Connor wrote:
>> 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.
> 
> I don't think this has been an issue so far on other platforms..
> 
> Do you have some more details?
> 
> Konrad

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

[Gekko]

Hi Xilin,

Thank you for the response.

I appreciate the offer to take over your patch set to move things 
forward. However, I feel I must respectfully decline. This is mainly due 
to my lack of experience with both upstream kernel development on this 
hardware and the patch management process itself. It would be 
irresponsible of me to take on something that I'm not knowledgeable 
enough to ensure successful completion.

I'm happy to work with you to help in any other way that I can such as 
testing patches, but I think you should maintain ownership of the 
patch-set and submission process, at least for now.

One of the reasons I withdrew my own patch-set is that from what I can 
see your series covers everything I was trying to achieve, and does it 
correctly :-)

The only one that isn't covered is the patch for early TCS 
initialisation that I'm discussing with Konrad which may be unnecessary 
anyway.

Graham

On 24/05/2026 13:58, Xilin Wu wrote:
> 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
> 

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

[Gekko]

Hi Konrad

I completely agree.

This patch is a temporary hardware workaround for RA620 bridge support 
and should not have been submitted. Please disregard.

Graham

On 22/05/2026 21:28, Konrad Dybcio wrote:
> 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

[Xilin Wu]

On 5/28/2026 4:43 AM, Gekko wrote:
> Hi Xilin,
> 
> Thank you for the response.
> 
> I appreciate the offer to take over your patch set to move things 
> forward. However, I feel I must respectfully decline. This is mainly due 
> to my lack of experience with both upstream kernel development on this 
> hardware and the patch management process itself. It would be 
> irresponsible of me to take on something that I'm not knowledgeable 
> enough to ensure successful completion.
> 
> I'm happy to work with you to help in any other way that I can such as 
> testing patches, but I think you should maintain ownership of the patch- 
> set and submission process, at least for now.
> 
> One of the reasons I withdrew my own patch-set is that from what I can 
> see your series covers everything I was trying to achieve, and does it 
> correctly :-)
> 
> The only one that isn't covered is the patch for early TCS 
> initialisation that I'm discussing with Konrad which may be unnecessary 
> anyway.
> 
> Graham
> 

Hi Graham,

Thanks, I understand your point.

I appreciate your offer to help with testing. I will do my best to move 
this series forward once I get the current work off my plate.

Thanks again for your help.

> On 24/05/2026 13:58, Xilin Wu wrote:
>> 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 1/6] soc: qcom: rpmh-rsc: Skip TCS init when RSC is managed by firmware

[Konrad Dybcio]

On 5/27/26 10:30 PM, Gekko wrote:
> Hi Konrad,
> 
> This one is confusing.
> 
> I started the bring-up on this board on gentoo-sources 6.18.18 but the board would not boot. After an almost subliminal flash of tux the board would lock every time.I found the solution from PostmarketOS who obviously faced the same issue which formed the genesis of this patch. With this patch applied the board booted fine so I've applied it ever since.
> 
> However, as a result of your response here I tried booting my current kernel (gentoo-sources 7.0.10) without the patch and to my surprise it booted just fine. This leaves a few options, including:
> 1) the kernel source has changed
> 2) this is a firmware issue and a firmware update fixed it
> 3) It's a timing issue.
> 
> To eliminate 2 I would have to test 6.18.18 with the current firmware, then regress the firmware and test again. The do the same with 7.0.10. I can't honestly recall whether the firmware upgrade was before or after this issue first appeared.
> 
> If it's a timing issue it's a bit more concerning. If the kernel is taking slightly longer to initialise before calling rpmh_probe_tcs_config() then it may just be missing the solver activation, everything appears to work and nobody is any the wiser. If the existing solver code doesn't deal with early firmware TCS initialisation then it could, under some circumstances, lead to the security reset that I was seeing. This patch specifically tests for that case.
> 
> Based on the AI review feedback I've also modified the patch to not simply return early but to just skip the sensitive parts of the code to allow any other setup to complete normally.
> 
> My current objective evidence is that the board boots without this patch and it's quite possible this patch is unnecessary if the above is incorrect.

I would skew towards this being a firmware issue. But I'm interested
in any findings you encounter.

Maybe +Maulik could know more

Konrad