[PATCH V3 0/5] Enable ADSP and CDSP for Glymur SoC

[PATCH V3 0/5] Enable ADSP and CDSP for Glymur SoC

[Sibi Sankar]

From: Sibi Sankar <quic_sibis@quicinc.com>

Qualcomm Glymur SoC variants predominantly boot Linux at EL2. This means
that the firmware streams of the remote processors are managed in kernel
and not in Gunyah hypervisor. Given that the Peripheral Image Loader for
Qualcomm SoCs now support running Linux Host at EL2 [1], this series
documents and enables ADSP and CDSP on Qualcomm Glymur SoCs with its
fastrpc nodes. A few variants of the SoC are expected to run Linux at EL1
hence the iommus properties are left optional.

[1] - https://lore.kernel.org/all/20260105-kvmrprocv10-v10-0-022e96815380@oss.qualcomm.com/

Changes in v3:
- A few variants of the SoC are expected to run Linux at EL1 hence the
  iommus properties are left optional.
- Add fastrpc bindings and nodes.
- Link to v2: https://lore.kernel.org/all/20251029-knp-remoteproc-v2-0-6c81993b52ea@oss.qualcomm.com/

Changes in v2:
- Combined into Kaanapali series since they are fully compatible.
- Link to v1: https://lore.kernel.org/all/20250924183726.509202-1-sibi.sankar@oss.qualcomm.com/

Dependencies:
dt-bindings:
1. https://lore.kernel.org/all/20260114-knp-remoteproc-v4-1-fcf0b04d01af@oss.qualcomm.com/
2. https://lore.kernel.org/all/20260114-knp-remoteproc-v4-2-fcf0b04d01af@oss.qualcomm.com/

Base-glymur support:
1. https://lore.kernel.org/lkml/20260122-upstream_v3_glymur_introduction-v6-0-245f408ed82a@oss.qualcomm.com/

Sibi Sankar (5):
  dt-bindings: remoteproc: qcom,sm8550-pas: Add Glymur ADSP
  dt-bindings: remoteproc: qcom,sm8550-pas: Add Glymur CDSP
  dt-bindings: misc: qcom,fastrpc: Add compatible for Glymur
  arm64: dts: qcom: glymur: Add ADSP and CDSP for Glymur SoC
  arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

 .../bindings/misc/qcom,fastrpc.yaml           |  11 +-
 .../bindings/remoteproc/qcom,sm8550-pas.yaml  |   4 +
 arch/arm64/boot/dts/qcom/glymur-crd.dts       |  14 +
 arch/arm64/boot/dts/qcom/glymur.dtsi          | 286 ++++++++++++++++++
 4 files changed, 312 insertions(+), 3 deletions(-)

-- 
2.34.1

[PATCH V3 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Add Glymur ADSP

[Sibi Sankar]

Document compatible for Qualcomm Glymur ADSP PAS which is fully
compatible with Qualcomm Kaanapali ADSP PAS.

Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---

Changes in v3:
- A few variants of the SoC are expected to run Linux at EL1 hence the
  iommus properties are left optional.
- Link to v2: https://lore.kernel.org/all/20251029-knp-remoteproc-v2-0-6c81993b52ea@oss.qualcomm.com/

 .../devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml         | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
index b117c82b057b..fb6e0b4f54e8 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -29,6 +29,7 @@ properties:
           - qcom,x1e80100-cdsp-pas
       - items:
           - enum:
+              - qcom,glymur-adsp-pas
               - qcom,kaanapali-adsp-pas
               - qcom,sm8750-adsp-pas
           - const: qcom,sm8550-adsp-pas
@@ -101,6 +102,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - qcom,glymur-adsp-pas
               - qcom,kaanapali-adsp-pas
               - qcom,kaanapali-cdsp-pas
               - qcom,sm8750-adsp-pas
-- 
2.34.1

Re: [PATCH V3 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Add Glymur ADSP

[Krzysztof Kozlowski]

On Thu, Jan 29, 2026 at 05:43:54AM +0530, Sibi Sankar wrote:
> Document compatible for Qualcomm Glymur ADSP PAS which is fully
> compatible with Qualcomm Kaanapali ADSP PAS.
> 
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> ---
> 
> Changes in v3:
> - A few variants of the SoC are expected to run Linux at EL1 hence the
>   iommus properties are left optional.
> - Link to v2: https://lore.kernel.org/all/20251029-knp-remoteproc-v2-0-6c81993b52ea@oss.qualcomm.com/
> 
>  .../devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml         | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> index b117c82b057b..fb6e0b4f54e8 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> @@ -29,6 +29,7 @@ properties:
>            - qcom,x1e80100-cdsp-pas
>        - items:
>            - enum:
> +              - qcom,glymur-adsp-pas
>                - qcom,kaanapali-adsp-pas

There is no such hunk... I think this continues my comments from Sep/Oct
2025 that creating such patches, with multiple dependencies makes more
difficult to review.

I mark it as not applicable, please send when your dependencies hit the
tree so I can review it in proper context.

Best regards,
Krzysztof

Re: [PATCH V3 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Add Glymur ADSP

[Sibi Sankar]

On 2/5/2026 4:04 PM, Krzysztof Kozlowski wrote:
> On Thu, Jan 29, 2026 at 05:43:54AM +0530, Sibi Sankar wrote:
>> Document compatible for Qualcomm Glymur ADSP PAS which is fully
>> compatible with Qualcomm Kaanapali ADSP PAS.
>>
>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>> ---
>>
>> Changes in v3:
>> - A few variants of the SoC are expected to run Linux at EL1 hence the
>>    iommus properties are left optional.
>> - Link to v2: https://lore.kernel.org/all/20251029-knp-remoteproc-v2-0-6c81993b52ea@oss.qualcomm.com/
>>
>>   .../devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml         | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
>> index b117c82b057b..fb6e0b4f54e8 100644
>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
>> @@ -29,6 +29,7 @@ properties:
>>             - qcom,x1e80100-cdsp-pas
>>         - items:
>>             - enum:
>> +              - qcom,glymur-adsp-pas
>>                 - qcom,kaanapali-adsp-pas
> There is no such hunk... I think this continues my comments from Sep/Oct
> 2025 that creating such patches, with multiple dependencies makes more
> difficult to review.
Hey Krzysztof, Thanks for taking time to review the series :) I'll give 
some more context here to ensure that your comments were followed and 
this is just a one-off. This patch was held off from the dependent 
Kaanapali patches since it wasn't clear at that time if this SoC would 
be running at EL1. Only with that confirmation and given that dependent 
patch was on the list for a couple of weeks with Rbs, this series got 
posted out. -Sibi
> I mark it as not applicable, please send when your dependencies hit the
> tree so I can review it in proper context.
>
> Best regards,
> Krzysztof
>

[PATCH V3 2/5] dt-bindings: remoteproc: qcom,sm8550-pas: Add Glymur CDSP

[Sibi Sankar]

Document compatible for Qualcomm Glymur CDSP PAS which is fully
compatible with Qualcomm Kaanapali CDSP PAS.

Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---

Changes in v3:
- A few variants of the SoC are expected to run Linux at EL1 hence the
  iommus properties are left optional.
- Link to v2: https://lore.kernel.org/all/20251029-knp-remoteproc-v2-0-6c81993b52ea@oss.qualcomm.com/

 .../devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml         | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
index fb6e0b4f54e8..6a29d239ef41 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -35,6 +35,7 @@ properties:
           - const: qcom,sm8550-adsp-pas
       - items:
           - enum:
+              - qcom,glymur-cdsp-pas
               - qcom,kaanapali-cdsp-pas
           - const: qcom,sm8550-cdsp-pas
       - items:
@@ -103,6 +104,7 @@ allOf:
           contains:
             enum:
               - qcom,glymur-adsp-pas
+              - qcom,glymur-cdsp-pas
               - qcom,kaanapali-adsp-pas
               - qcom,kaanapali-cdsp-pas
               - qcom,sm8750-adsp-pas
-- 
2.34.1

[PATCH V3 3/5] dt-bindings: misc: qcom,fastrpc: Add compatible for Glymur

[Sibi Sankar]

Document compatible for Qualcomm Glymur fastrpc which is fully compatible
with Qualcomm Kaanapali fastrpc.

Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---
 .../devicetree/bindings/misc/qcom,fastrpc.yaml        | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
index d8e47db677cc..ca830dd06de2 100644
--- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
+++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
@@ -18,9 +18,14 @@ description: |
 
 properties:
   compatible:
-    enum:
-      - qcom,kaanapali-fastrpc
-      - qcom,fastrpc
+    oneOf:
+      - enum:
+          - qcom,kaanapali-fastrpc
+          - qcom,fastrpc
+      - items:
+          - enum:
+              - qcom,glymur-fastrpc
+          - const: qcom,kaanapali-fastrpc
 
   label:
     enum:
-- 
2.34.1

Re: [PATCH V3 3/5] dt-bindings: misc: qcom,fastrpc: Add compatible for Glymur

[Bjorn Andersson]

On Thu, Jan 29, 2026 at 05:43:56AM +0530, Sibi Sankar wrote:
> Document compatible for Qualcomm Glymur fastrpc which is fully compatible
> with Qualcomm Kaanapali fastrpc.
> 

I assume this means that you have successfully called at least one
FastRPC function on Glymur - with the WP firmware?

Regards,
Bjorn

> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/misc/qcom,fastrpc.yaml        | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
> index d8e47db677cc..ca830dd06de2 100644
> --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
> +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
> @@ -18,9 +18,14 @@ description: |
>  
>  properties:
>    compatible:
> -    enum:
> -      - qcom,kaanapali-fastrpc
> -      - qcom,fastrpc
> +    oneOf:
> +      - enum:
> +          - qcom,kaanapali-fastrpc
> +          - qcom,fastrpc
> +      - items:
> +          - enum:
> +              - qcom,glymur-fastrpc
> +          - const: qcom,kaanapali-fastrpc
>  
>    label:
>      enum:
> -- 
> 2.34.1
> 

Re: [PATCH V3 3/5] dt-bindings: misc: qcom,fastrpc: Add compatible for Glymur

[Sibi Sankar]

On 2/23/2026 10:01 PM, Bjorn Andersson wrote:
> On Thu, Jan 29, 2026 at 05:43:56AM +0530, Sibi Sankar wrote:
>> Document compatible for Qualcomm Glymur fastrpc which is fully compatible
>> with Qualcomm Kaanapali fastrpc.
>>
> I assume this means that you have successfully called at least one
> FastRPC function on Glymur - with the WP firmware?

Hey Bjorn,

Yes, we did verify fastrpc on both ADSP/CDSP on the firmware that
was upstreamed to linux-firmware on WP Glymur CRDs.

-Sibi

> Regards,
> Bjorn
>
>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>> ---
>>   .../devicetree/bindings/misc/qcom,fastrpc.yaml        | 11 ++++++++---
>>   1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
>> index d8e47db677cc..ca830dd06de2 100644
>> --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
>> +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
>> @@ -18,9 +18,14 @@ description: |
>>   
>>   properties:
>>     compatible:
>> -    enum:
>> -      - qcom,kaanapali-fastrpc
>> -      - qcom,fastrpc
>> +    oneOf:
>> +      - enum:
>> +          - qcom,kaanapali-fastrpc
>> +          - qcom,fastrpc
>> +      - items:
>> +          - enum:
>> +              - qcom,glymur-fastrpc
>> +          - const: qcom,kaanapali-fastrpc
>>   
>>     label:
>>       enum:
>> -- 
>> 2.34.1
>>

[PATCH V3 4/5] arm64: dts: qcom: glymur: Add ADSP and CDSP for Glymur SoC

[Sibi Sankar]

Add remoteproc PAS loader for ADSP and CDSP with its fastrpc nodes.

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

diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 16a3c3ecf97a..4521752e1628 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -3346,6 +3346,122 @@ ipcc: mailbox@3e04000 {
 			#mbox-cells = <2>;
 		};
 
+		remoteproc_adsp: remoteproc@6800000 {
+			compatible = "qcom,glymur-adsp-pas", "qcom,sm8550-adsp-pas";
+			reg = <0x0 0x06800000 0x0 0x10000>;
+
+			iommus = <&apps_smmu 0x1000 0x0>;
+
+			interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_adsp_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog",
+					  "fatal",
+					  "ready",
+					  "handover",
+					  "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "xo";
+
+			interconnects = <&lpass_lpicx_noc MASTER_LPASS_PROC QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+
+			power-domains = <&rpmhpd RPMHPD_LCX>,
+					<&rpmhpd RPMHPD_LMX>;
+			power-domain-names = "lcx",
+					     "lmx";
+
+			memory-region = <&adspslpi_mem>, <&q6_adsp_dtb_mem>;
+
+			qcom,qmp = <&aoss_qmp>;
+
+			qcom,smem-states = <&smp2p_adsp_out 0>;
+			qcom,smem-state-names = "stop";
+
+			status = "disabled";
+
+			remoteproc_adsp_glink: glink-edge {
+				interrupts-extended = <&ipcc IPCC_MPROC_LPASS
+							     IPCC_MPROC_SIGNAL_GLINK_QMP
+							     IRQ_TYPE_EDGE_RISING>;
+
+				mboxes = <&ipcc IPCC_MPROC_LPASS
+						IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+				qcom,remote-pid = <2>;
+
+				label = "lpass";
+
+				fastrpc {
+					compatible = "qcom,glymur-fastrpc", "qcom,kaanapali-fastrpc";
+					qcom,glink-channels = "fastrpcglink-apps-dsp";
+					label = "adsp";
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					compute-cb@3 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <3>;
+
+						iommus = <&apps_smmu 0x1003 0x80>,
+							 <&apps_smmu 0x1043 0x20>;
+						dma-coherent;
+					};
+
+					compute-cb@4 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <4>;
+
+						iommus = <&apps_smmu 0x1004 0x80>,
+							 <&apps_smmu 0x1044 0x20>;
+						dma-coherent;
+					};
+
+					compute-cb@5 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <5>;
+
+						iommus = <&apps_smmu 0x1005 0x80>,
+							 <&apps_smmu 0x1045 0x20>;
+						dma-coherent;
+					};
+
+					compute-cb@6 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <6>;
+
+						iommus = <&apps_smmu 0x1006 0x80>,
+							 <&apps_smmu 0x1046 0x20>;
+						dma-coherent;
+					};
+
+					compute-cb@7 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <7>;
+
+						iommus = <&apps_smmu 0x1007 0x40>,
+							 <&apps_smmu 0x1067 0x0>,
+							 <&apps_smmu 0x1087 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@8 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <8>;
+
+						iommus = <&apps_smmu 0x1008 0x80>,
+							 <&apps_smmu 0x1048 0x20>;
+						dma-coherent;
+					};
+				};
+			};
+		};
+
 		lpass_lpiaon_noc: interconnect@7400000 {
 			compatible = "qcom,glymur-lpass-lpiaon-noc";
 			reg = <0x0 0x07400000 0x0 0x19080>;
@@ -4692,6 +4808,176 @@ nsp_noc: interconnect@320c0000 {
 			#interconnect-cells = <2>;
 		};
 
+		remoteproc_cdsp: remoteproc@32300000 {
+			compatible = "qcom,glymur-cdsp-pas", "qcom,sm8550-cdsp-pas";
+			reg = <0x0 0x32300000 0x0 0x10000>;
+
+			iommus = <&apps_smmu 0x2000 0x400>;
+
+			interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_cdsp_in 1 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_cdsp_in 2 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_cdsp_in 3 IRQ_TYPE_EDGE_RISING>,
+					      <&smp2p_cdsp_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog",
+					  "fatal",
+					  "ready",
+					  "handover",
+					  "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "xo";
+
+			interconnects = <&nsp_noc MASTER_CDSP_PROC QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+
+			power-domains = <&rpmhpd RPMHPD_CX>,
+					<&rpmhpd RPMHPD_MXC>,
+					<&rpmhpd RPMHPD_NSP>;
+			power-domain-names = "cx",
+					     "mxc",
+					     "nsp";
+
+			memory-region = <&cdsp_mem>, <&q6_cdsp_dtb_mem>;
+			qcom,qmp = <&aoss_qmp>;
+			qcom,smem-states = <&smp2p_cdsp_out 0>;
+			qcom,smem-state-names = "stop";
+
+			status = "disabled";
+
+			glink-edge {
+				interrupts-extended = <&ipcc IPCC_MPROC_CDSP
+							     IPCC_MPROC_SIGNAL_GLINK_QMP
+							     IRQ_TYPE_EDGE_RISING>;
+				mboxes = <&ipcc IPCC_MPROC_CDSP
+						IPCC_MPROC_SIGNAL_GLINK_QMP>;
+				qcom,remote-pid = <5>;
+				label = "cdsp";
+
+				fastrpc {
+					compatible = "qcom,glymur-fastrpc", "qcom,kaanapali-fastrpc";
+					qcom,glink-channels = "fastrpcglink-apps-dsp";
+					label = "cdsp";
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					compute-cb@1 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <1>;
+
+						iommus = <&apps_smmu 0x2001 0x440>,
+							 <&apps_smmu 0x1961 0x0>,
+							 <&apps_smmu 0x19c1 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@2 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <2>;
+
+						iommus = <&apps_smmu 0x2002 0x440>,
+							 <&apps_smmu 0x1962 0x0>,
+							 <&apps_smmu 0x19c2 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@3 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <3>;
+
+						iommus = <&apps_smmu 0x2003 0x440>,
+							 <&apps_smmu 0x1963 0x0>,
+							 <&apps_smmu 0x19c3 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@4 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <4>;
+
+						iommus = <&apps_smmu 0x2004 0x440>,
+							 <&apps_smmu 0x1964 0x0>,
+							 <&apps_smmu 0x19c4 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@5 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <5>;
+
+						iommus = <&apps_smmu 0x2005 0x440>,
+							 <&apps_smmu 0x1965 0x0>,
+							 <&apps_smmu 0x19c5 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@6 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <6>;
+
+						iommus = <&apps_smmu 0x2006 0x440>,
+							 <&apps_smmu 0x1966 0x0>,
+							 <&apps_smmu 0x19c6 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@7 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <7>;
+
+						iommus = <&apps_smmu 0x2007 0x440>,
+							 <&apps_smmu 0x1967 0x0>,
+							 <&apps_smmu 0x19c7 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@8 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <8>;
+
+						iommus = <&apps_smmu 0x2008 0x440>,
+							 <&apps_smmu 0x1968 0x0>,
+							 <&apps_smmu 0x19c8 0x0>;
+						dma-coherent;
+					};
+
+					/* note: compute-cb@9 is secure */
+
+					compute-cb@10 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <10>;
+
+						iommus = <&apps_smmu 0x200c 0x440>,
+							 <&apps_smmu 0x196c 0x0>,
+							 <&apps_smmu 0x19cc 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@11 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <11>;
+
+						iommus = <&apps_smmu 0x200d 0x440>,
+							 <&apps_smmu 0x196d 0x0>,
+							 <&apps_smmu 0x19cd 0x0>;
+						dma-coherent;
+					};
+
+					compute-cb@12 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <12>;
+
+						iommus = <&apps_smmu 0x200e 0x440>,
+							 <&apps_smmu 0x196e 0x0>,
+							 <&apps_smmu 0x19ce 0x0>;
+						dma-coherent;
+					};
+				};
+			};
+		};
+
 		imem: sram@81e08000 {
 			compatible = "mmio-sram";
 			reg = <0x0 0x81e08600 0x0 0x300>;
-- 
2.34.1

Re: [PATCH V3 4/5] arm64: dts: qcom: glymur: Add ADSP and CDSP for Glymur SoC

[Konrad Dybcio]

On 1/29/26 1:13 AM, Sibi Sankar wrote:
> Add remoteproc PAS loader for ADSP and CDSP with its fastrpc nodes.
> 
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> ---

[...]

> +				fastrpc {
> +					compatible = "qcom,glymur-fastrpc", "qcom,kaanapali-fastrpc";
> +					qcom,glink-channels = "fastrpcglink-apps-dsp";
> +					label = "adsp";
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +
> +					compute-cb@3 {
> +						compatible = "qcom,fastrpc-compute-cb";
> +						reg = <3>;
> +
> +						iommus = <&apps_smmu 0x1003 0x80>,
> +							 <&apps_smmu 0x1043 0x20>;

0x104x -> 0x106x for all children here, the result is the same but let's
match docs so that no one has questions down the line

[...]


> @@ -4692,6 +4808,176 @@ nsp_noc: interconnect@320c0000 {
>  			#interconnect-cells = <2>;
>  		};
>  
> +		remoteproc_cdsp: remoteproc@32300000 {
> +			compatible = "qcom,glymur-cdsp-pas", "qcom,sm8550-cdsp-pas";
> +			reg = <0x0 0x32300000 0x0 0x10000>;
> +
> +			iommus = <&apps_smmu 0x2000 0x400>;

0x2400 (same reasoning)

[...]

> +				fastrpc {
> +					compatible = "qcom,glymur-fastrpc", "qcom,kaanapali-fastrpc";
> +					qcom,glink-channels = "fastrpcglink-apps-dsp";
> +					label = "cdsp";
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +
> +					compute-cb@1 {
> +						compatible = "qcom,fastrpc-compute-cb";
> +						reg = <1>;
> +
> +						iommus = <&apps_smmu 0x2001 0x440>,

0x200x -> 0x240x (again)

Otherwise lgtm

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH V3 4/5] arm64: dts: qcom: glymur: Add ADSP and CDSP for Glymur SoC

[Abel Vesa]

On 26-01-29 05:43:57, Sibi Sankar wrote:
> Add remoteproc PAS loader for ADSP and CDSP with its fastrpc nodes.
> 
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>

Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

[PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Sibi Sankar]

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";
+};
+
 &tlmm {
 	gpio-reserved-ranges = <4 4>, /* EC TZ Secure I3C */
 			       <10 2>, /* OOB UART */
-- 
2.34.1

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Konrad Dybcio]

On 1/29/26 1:13 AM, Sibi Sankar wrote:
> 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 <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Dmitry Baryshkov]

On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:
> On 1/29/26 1:13 AM, Sibi Sankar wrote:
> > 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 <konrad.dybcio@oss.qualcomm.com>

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.

-- 
With best wishes
Dmitry

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Konrad Dybcio]

On 1/31/26 8:54 AM, Dmitry Baryshkov wrote:
> On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:
>> On 1/29/26 1:13 AM, Sibi Sankar wrote:
>>> 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 <konrad.dybcio@oss.qualcomm.com>
> 
> 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

Konrad

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Dmitry Baryshkov]

On Mon, Feb 02, 2026 at 11:16:19AM +0100, Konrad Dybcio wrote:
> On 1/31/26 8:54 AM, Dmitry Baryshkov wrote:
> > On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:
> >> On 1/29/26 1:13 AM, Sibi Sankar wrote:
> >>> 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 <konrad.dybcio@oss.qualcomm.com>
> > 
> > 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.

-- 
With best wishes
Dmitry

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Sibi Sankar]

On 2/3/2026 6:09 PM, Dmitry Baryshkov wrote:
> On Mon, Feb 02, 2026 at 11:16:19AM +0100, Konrad Dybcio wrote:
>> On 1/31/26 8:54 AM, Dmitry Baryshkov wrote:
>>> On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:
>>>> On 1/29/26 1:13 AM, Sibi Sankar wrote:
>>>>> 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 <konrad.dybcio@oss.qualcomm.com>
>>> 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

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Dmitry Baryshkov]

On Mon, 23 Feb 2026 at 11:09, Sibi Sankar <sibi.sankar@oss.qualcomm.com> wrote:
>
>
> On 2/3/2026 6:09 PM, Dmitry Baryshkov wrote:
> > On Mon, Feb 02, 2026 at 11:16:19AM +0100, Konrad Dybcio wrote:
> >> On 1/31/26 8:54 AM, Dmitry Baryshkov wrote:
> >>> On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:
> >>>> On 1/29/26 1:13 AM, Sibi Sankar wrote:
> >>>>> 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 <konrad.dybcio@oss.qualcomm.com>
> >>> 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?

Thank you for a prompt reaction, it took just 20 days. During that
time we could have fixed WP firmware filenames, but... linux-firmware
got released just two days ago, so we can't fix that anymore. Now we
don't have any other option than to use a non-standard name for IoT
firmware when it comes later.

>
> -Sibi
>


-- 
With best wishes
Dmitry

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Sibi Sankar]

On 2/23/2026 10:44 PM, Dmitry Baryshkov wrote:
> On Mon, 23 Feb 2026 at 11:09, Sibi Sankar <sibi.sankar@oss.qualcomm.com> wrote:
>>
>> On 2/3/2026 6:09 PM, Dmitry Baryshkov wrote:
>>> On Mon, Feb 02, 2026 at 11:16:19AM +0100, Konrad Dybcio wrote:
>>>> On 1/31/26 8:54 AM, Dmitry Baryshkov wrote:
>>>>> On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:
>>>>>> On 1/29/26 1:13 AM, Sibi Sankar wrote:
>>>>>>> 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 <konrad.dybcio@oss.qualcomm.com>
>>>>> 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?
> Thank you for a prompt reaction, it took just 20 days. During that
> time we could have fixed WP firmware filenames, but... linux-firmware

Hey Dmitry,

I'm really sorry that this happened this way :( but I was out
on vacation the past three weeks getting married. A quick
review comment on the firmware pull request for naming
change request would also sufficed in the interim. Also to address
some of your concerns there aren't any plans to push an iot
specific ADSP/CDSP firmware for Glymur reference devices.
Also, this series already warrants a re-post so I can still
accommodate your naming requests with corresponding
updates to linux-firmware.

-Sibi

> got released just two days ago, so we can't fix that anymore. Now we
> don't have any other option than to use a non-standard name for IoT
> firmware when it comes later.
>
>> -Sibi
>>
>

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Dmitry Baryshkov]

On Tue, Feb 24, 2026 at 11:48:00AM +0530, Sibi Sankar wrote:
> 
> On 2/23/2026 10:44 PM, Dmitry Baryshkov wrote:
> > On Mon, 23 Feb 2026 at 11:09, Sibi Sankar <sibi.sankar@oss.qualcomm.com> wrote:
> > > 
> > > On 2/3/2026 6:09 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Feb 02, 2026 at 11:16:19AM +0100, Konrad Dybcio wrote:
> > > > > On 1/31/26 8:54 AM, Dmitry Baryshkov wrote:
> > > > > > On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:
> > > > > > > On 1/29/26 1:13 AM, Sibi Sankar wrote:
> > > > > > > > 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 <konrad.dybcio@oss.qualcomm.com>
> > > > > > 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?
> > Thank you for a prompt reaction, it took just 20 days. During that
> > time we could have fixed WP firmware filenames, but... linux-firmware
> 
> Hey Dmitry,
> 
> I'm really sorry that this happened this way :( but I was out
> on vacation the past three weeks getting married. A quick
> review comment on the firmware pull request for naming
> change request would also sufficed in the interim. Also to address
> some of your concerns there aren't any plans to push an iot
> specific ADSP/CDSP firmware for Glymur reference devices.

There are no plans to push or there are no plans to have it?

> Also, this series already warrants a re-post so I can still
> accommodate your naming requests with corresponding
> updates to linux-firmware.

Yes, but the linux-firmware has been released with these file names, so
you can't just change them. You will have to provide
backwards-compatibility links, which defeats the purpose.

> 
> -Sibi
> 
> > got released just two days ago, so we can't fix that anymore. Now we
> > don't have any other option than to use a non-standard name for IoT
> > firmware when it comes later.
> > 
> > > -Sibi
> > > 
> > 

-- 
With best wishes
Dmitry

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Sibi Sankar]

On 2/24/2026 12:00 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 24, 2026 at 11:48:00AM +0530, Sibi Sankar wrote:
>> On 2/23/2026 10:44 PM, Dmitry Baryshkov wrote:
>>> On Mon, 23 Feb 2026 at 11:09, Sibi Sankar <sibi.sankar@oss.qualcomm.com> wrote:
>>>> On 2/3/2026 6:09 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, Feb 02, 2026 at 11:16:19AM +0100, Konrad Dybcio wrote:
>>>>>> On 1/31/26 8:54 AM, Dmitry Baryshkov wrote:
>>>>>>> On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote:
>>>>>>>> On 1/29/26 1:13 AM, Sibi Sankar wrote:
>>>>>>>>> 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 <konrad.dybcio@oss.qualcomm.com>
>>>>>>> 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?
>>> Thank you for a prompt reaction, it took just 20 days. During that
>>> time we could have fixed WP firmware filenames, but... linux-firmware
>> Hey Dmitry,
>>
>> I'm really sorry that this happened this way :( but I was out
>> on vacation the past three weeks getting married. A quick
>> review comment on the firmware pull request for naming
>> change request would also sufficed in the interim. Also to address
>> some of your concerns there aren't any plans to push an iot
>> specific ADSP/CDSP firmware for Glymur reference devices.
> There are no plans to push or there are no plans to have it?

I've been told that the plan is to use the same firmware for IOT SKUs as 
well. Also in case they do update the firmware in the future, it would 
be tested for any regression against WP targets.

>> Also, this series already warrants a re-post so I can still
>> accommodate your naming requests with corresponding
>> updates to linux-firmware.
> Yes, but the linux-firmware has been released with these file names, so
> you can't just change them. You will have to provide
> backwards-compatibility links, which defeats the purpose.
>
>> -Sibi
>>
>>> got released just two days ago, so we can't fix that anymore. Now we
>>> don't have any other option than to use a non-standard name for IoT
>>> firmware when it comes later.
>>>
>>>> -Sibi
>>>>

Re: [PATCH V3 5/5] arm64: dts: qcom: glymur-crd: Enable ADSP and CDSP

[Abel Vesa]

On 26-01-29 05:43:58, Sibi Sankar wrote:
> Enable ADSP and CDSP on Glymur CRD board.
> 
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>

Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>