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

[sashiko-bot@kernel.org]

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