On 2/3/2026 6:09 PM, Dmitry Baryshkov wrote:

On Mon, Feb 02, 2026 at 11:16:19AM +0100, Konrad Dybcio wrote:

quoted

On 1/31/26 8:54 AM, Dmitry Baryshkov wrote:

quoted

On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:

quoted

On 1/29/26 1:13 AM, Sibi Sankar wrote:

quoted

Enable ADSP and CDSP on Glymur CRD board.

Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---
  arch/arm64/boot/dts/qcom/glymur-crd.dts | 14 ++++++++++++++
  1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
index 0899214465ac..0eed4faa8b07 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts

@@ -487,6 +487,20 @@ &pon_resin {
  	status = "okay";
  };
  
+&remoteproc_adsp {
+	firmware-name = "qcom/glymur/adsp.mbn",
+			"qcom/glymur/adsp_dtb.mbn";
+
+	status = "okay";
+};
+
+&remoteproc_cdsp {
+	firmware-name = "qcom/glymur/cdsp.mbn",
+			"qcom/glymur/cdsp_dtb.mbn";
+
+	status = "okay";
+};

Please make sure it gets to L-F (only Kaanapali is there right now)

Reviewed-by: Konrad Dybcio <redacted>

Hmm, looking at x1e80100-crd which references qcom/x1e80100/adsp.mbn,
but the firmware in linux-firmware is (now) targeting IoT devices,
should we use WoA-like names for firmware on Glymur CRD instead
(qcadsp-something.mbn). It would match what was done for the SC8280XP
CRD.

I think it's simply time to stop pretending the firmware is generic
(some fw simply isn't and some fw may come from different/incompatible
branchpoints) and include a board name in the path

Well... CDSP is usually generic, except for WP vs non-WP.

Hey Dmitry/Konrad,

Thanks for taking time to review the series :)

The ADSP/CDSP firmware that got upstreamed to linux-firmware got their
functionality tested on Glymur WP CRD devices.  Given that the firmware
has already landed, can I continue to use the same name as the patch and
have a different name for other boards if something specific has to be 
pushed
for IOT?

-Sibi