arm64: qcom: Enable additional hardware on Radxa Dragon Q6A

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.

Quoted 5 lines · 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.

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

Do you have some more details?

Konrad

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.

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 <[email protected]>

---
 drivers/firmware/qcom/qcom_scm.c | 1 +
 1 file changed, 1 insertion(+)

drivers/firmware/qcom/qcom_scm.c +1 -0

index 6b601a4b8..4702ad898 100644
@@ -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" },
 	{ }
 };
 

Signature · 1 line

2.53.0

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 <[email protected]>

---
 drivers/gpu/drm/msm/dp/dp_link.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/msm/dp/dp_link.h +0 -0

index 76125e9c0..ff0d8e99d 100644

Quoted 21 lines · 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 <[email protected]>

---
  drivers/gpu/drm/msm/dp/dp_link.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/msm/dp/dp_link.h +0 -0

index 76125e9c0..ff0d8e99d 100644

drivers/gpu/drm/msm/dp/dp_link.h struct msm_dp_link_info { · line 27

Quoted 5 lines

drivers/gpu/drm/msm/dp/dp_link.h +1 -1

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

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 <[email protected]>

---
 .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts +0 -0

index bb5a42b03..4003837ad 100644

arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts +15 -0

+
+&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";
+};

Signature · 1 line

2.53.0

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 <[email protected]>

---
  .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 85 +++++++++++++++++++
  1 file changed, 85 insertions(+)

arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts +18 -0

index 4003837ad..e8ad6e666 100644
@@ -1113,3 +1113,88 @@ &pcie1 {
  &eud {
  	status = "disabled";
  };
+
+&gpucc {
+	status = "okay";
+};
+
+&gmu {
+	status = "okay";
+};
+
+&dispcc {
+	status = "okay";
+};
+
+&mdss {
+	status = "okay";
+};
+
+&tlmm {

arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts +57 -0

+		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";
+};

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 <[email protected]>

---
  .../dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 71 +++++++++++++++++++
  1 file changed, 71 insertions(+)

arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts +17 -0

index e8ad6e666..c16c3664e 100644
@@ -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>;

arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts +44 -0

+
+			/* 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";
+};

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

Quoted 19 lines · 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)

Quoted 8 lines

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

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

Quoted 43 lines · Graham O'Connor

Quoted 19 lines

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)

Quoted 8 lines

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