Re: [PATCH v1] arm64: dts: qcom: glymur-crd: add DisplayPort audio DAI link

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] arm64: dts: qcom: glymur-crd: dp-dai-link breaks sound probe on mahua-crd
- [Medium] arm64: dts: qcom: glymur-crd: missing mdss_dp0 DAI link and disabled mdss_dp1 on mahua-crd
--

commit 08a824dc35410c5805c76e45de4e1800714bcfaf
Author: Chiluka Rohith <rohith.chiluka@oss.qualcomm.com>

arm64: dts: qcom: glymur-crd: add DisplayPort audio DAI link

This commit adds a DisplayPort RX DAI link to the sound node in
glymur-crd.dtsi, connecting the q6apmbedai DISPLAY_PORT_RX_1 backend to the
mdss_dp1 controller.

> diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> index 58158b51fe295..eee75da201983 100644
> --- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> @@ -268,6 +268,22 @@ platform {
>  			};
>  		};
>  
> +		dp-dai-link {
> +			link-name = "DISPLAY_PORT-RX";
> +
> +			codec {
> +				sound-dai = <&mdss_dp1>;
> +			};

[Severity: High]
Does adding this dp-dai-link unconditionally in glymur-crd.dtsi break sound
card probing on mahua-crd?

In arch/arm64/boot/dts/qcom/glymur.dtsi, mdss_dp1 is disabled by default. It
is only enabled in arch/arm64/boot/dts/qcom/glymur-crd.dts:

&mdss_dp1 {
	status = "okay";
};

However, arch/arm64/boot/dts/qcom/mahua-crd.dts also includes glymur-crd.dtsi
without enabling mdss_dp1:

#include "mahua.dtsi"
#include "glymur-crd.dtsi"

When mahua-crd boots, x1e80100_platform_probe() -> qcom_snd_parse_of()
iterates over all available child nodes of /sound and calls
snd_soc_of_get_dai_link_codecs() -> snd_soc_of_get_dlc() ->
snd_soc_get_dlc():

sound/soc/qcom/common.c:qcom_snd_parse_of() {
	...
		if (codec) {
			ret = snd_soc_of_get_dai_link_codecs(dev, codec, link);
			if (ret < 0) {
				dev_err_probe(dev, ret,
					      "%s: codec dai not found\n", link->name);
				return ret;
			}
	...
}

Because mdss_dp1 remains disabled on mahua-crd, its ASoC component is never
registered, causing snd_soc_get_dlc() to return -EPROBE_DEFER permanently and
preventing the entire sound card (including speaker playback and VA DMIC
capture) from registering on Mahua CRD.

> +
> +			cpu {
> +				sound-dai = <&q6apmbedai DISPLAY_PORT_RX_1>;
> +			};
> +
> +			platform {
> +				sound-dai = <&q6apm>;
> +			};
> +		};

[Severity: Medium]
Should mdss_dp0 (DISPLAY_PORT_RX_0) also be wired up here, and should the node
and link names match the other qcom,glymur-sndcard boards?

Both USB Type-C connectors in arch/arm64/boot/dts/qcom/glymur-crd.dtsi route
DisplayPort (connector@0 via usb_0_qmpphy to mdss_dp0, and connector@1 via
usb_1_qmpphy to mdss_dp1), and arch/arm64/boot/dts/qcom/glymur-crd.dts enables
both mdss_dp0 and mdss_dp1:

&mdss_dp0 {
	status = "okay";
};

&mdss_dp0_out {
	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
};

&mdss_dp1 {
	status = "okay";
};

Additionally, sibling boards using the same sound card driver
(sound/soc/qcom/x1e80100.c), such as
arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts and
arch/arm64/boot/dts/qcom/x1-crd.dtsi, define both links using
displayport-0-dai-link and displayport-1-dai-link:

		displayport-0-dai-link {
			link-name = "DisplayPort0 Playback";

			cpu {
				sound-dai = <&q6apmbedai DISPLAY_PORT_RX_0>;
			};

			codec {
				sound-dai = <&mdss_dp0>;
			};

			platform {
				sound-dai = <&q6apm>;
			};
		};

		displayport-1-dai-link {
			link-name = "DisplayPort1 Playback";

Wait: if mdss_dp0 and mdss_dp1 are only enabled in glymur-crd.dts while
remaining disabled in mahua-crd.dts, should the DisplayPort DAI links either
be placed in glymur-crd.dts or have mdss_dp0 and mdss_dp1 enabled across the
boards that include glymur-crd.dtsi?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105104013.614413-1-rohith.chiluka@oss.qualcomm.com?part=1