[PATCH v2 0/2] arm64: dts: qcom: add CDSP FastRPC extended context bank

[PATCH v2 0/2] arm64: dts: qcom: add CDSP FastRPC extended context bank

[Vinayak Katoch]

Wire up the dedicated CDSP extended context bank on kaanapali and
glymur, enabling buffer mappings beyond the standard 34-bit IOVA limit.

The FastRPC driver identifies an extended context bank by the presence
of iommu-ranges on the compute-cb node. Each patch adds
iommu-ranges = <0x4 0x0 0xfc 0x0> on the designated compute-cb,
restricting IOVA allocations to the [16 GiB, ~1 TiB) window. The
fastrpc and glink ancestor nodes are bumped to #address-cells = <2>
and #size-cells = <2> to accommodate 64-bit iommu-ranges values, and
all existing compute-cb reg entries are updated to the four-cell format.

Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
---
Changes in v2:
- Replaced prerequisite change-ids with message-ids to fix patch-id
  flood on lore.
- Link to v1: https://lore.kernel.org/r/20261007-extended-mapping-dts-v1-0-b52eb8c3613d@oss.qualcomm.com

---
Vinayak Katoch (2):
      arm64: dts: qcom: kaanapali: add CDSP FastRPC extended context bank
      arm64: dts: qcom: glymur: add CDSP FastRPC extended context bank

 arch/arm64/boot/dts/qcom/glymur.dtsi    | 31 ++++++++++++++++++-------------
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 29 +++++++++++++++++------------
 2 files changed, 35 insertions(+), 25 deletions(-)
---
base-commit: 5c4d4169604b335c38bbc79bc1fc03042981fc6f
change-id: 20261006-extended-mapping-dts-f60dbc6221aa
prerequisite-message-id: <20260923-dup-sessions-v5-0-e953133a1827@oss.qualcomm.com>
prerequisite-patch-id: 425dc9414848bbc3f2a053d067195d849898e2ae
prerequisite-patch-id: 4fea14b47d11a5a3e18065d8cf3a461841ee2b86
prerequisite-patch-id: da0a3d55397a522ea4b77769e387df9faea8e024
prerequisite-message-id: <20261007-extended-mapping-v2-0-5dca3aa2c2d3@oss.qualcomm.com>
prerequisite-patch-id: 623ce2b8bb3c3109e8725b5c6da321c5319b2845
prerequisite-patch-id: 507349e8804b8b4ec2afb32f0bfe887ea0988e1e
prerequisite-patch-id: fad218522e72b993815db4b91d4a3fb69b1107c8
prerequisite-patch-id: 918c24e26e0bbcedc4ae2c73d80b9ad3854823aa

Best regards,
-- 
Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

[PATCH v2 1/2] arm64: dts: qcom: kaanapali: add CDSP FastRPC extended context bank

[Vinayak Katoch]

Wire up compute-cb@13 as the dedicated extended IOVA context bank by
adding iommu-ranges = <0x4 0x0 0xfc 0x0>, restricting allocations to
the [16 GiB, ~1 TiB) window. This allows large CDSP buffers to be
mapped beyond the standard 34-bit limit.

Bump #address-cells and #size-cells to <2> on the fastrpc and glink
ancestor nodes to accommodate 64-bit iommu-ranges values, and update
all compute-cb reg entries to the four-cell format accordingly.

Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 146eaf9f0b9a..2b00a813414e 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -6304,6 +6304,8 @@ remoteproc_cdsp: remoteproc@26300000 {
 			qcom,qmp = <&aoss_qmp>;
 			qcom,smem-states = <&smp2p_cdsp_out 0>;
 			qcom,smem-state-names = "stop";
+			#address-cells = <2>;
+			#size-cells = <2>;
 
 			status = "disabled";
 
@@ -6315,17 +6317,19 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
 						IPCC_MPROC_SIGNAL_GLINK_QMP>;
 				qcom,remote-pid = <5>;
 				label = "cdsp";
+				#address-cells = <2>;
+				#size-cells = <2>;
 
 				fastrpc {
 					compatible = "qcom,kaanapali-fastrpc";
 					qcom,glink-channels = "fastrpcglink-apps-dsp";
 					label = "cdsp";
-					#address-cells = <1>;
-					#size-cells = <0>;
+					#address-cells = <2>;
+					#size-cells = <2>;
 
 					compute-cb@1 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <1>;
+						reg = <0x0 0x1 0x0 0x0>;
 						iommus = <&apps_smmu 0x19c1 0x0>,
 							 <&apps_smmu 0x1961 0x0>,
 							 <&apps_smmu 0x0c21 0x0>,
@@ -6335,7 +6339,7 @@ compute-cb@1 {
 
 					compute-cb@2 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <2>;
+						reg = <0x0 0x2 0x0 0x0>;
 						iommus = <&apps_smmu 0x1962 0x0>,
 							 <&apps_smmu 0x0c02 0x20>,
 							 <&apps_smmu 0x0c42 0x0>,
@@ -6345,7 +6349,7 @@ compute-cb@2 {
 
 					compute-cb@3 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <3>;
+						reg = <0x0 0x3 0x0 0x0>;
 						iommus = <&apps_smmu 0x1963 0x0>,
 							 <&apps_smmu 0x0c23 0x0>,
 							 <&apps_smmu 0x0c03 0x40>,
@@ -6355,7 +6359,7 @@ compute-cb@3 {
 
 					compute-cb@4 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <4>;
+						reg = <0x0 0x4 0x0 0x0>;
 						iommus = <&apps_smmu 0x1964 0x0>,
 							 <&apps_smmu 0x0c44 0x0>,
 							 <&apps_smmu 0x0c04 0x20>,
@@ -6365,7 +6369,7 @@ compute-cb@4 {
 
 					compute-cb@5 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <5>;
+						reg = <0x0 0x5 0x0 0x0>;
 						iommus = <&apps_smmu 0x1965 0x0>,
 							 <&apps_smmu 0x0c45 0x0>,
 							 <&apps_smmu 0x0c05 0x20>,
@@ -6375,7 +6379,7 @@ compute-cb@5 {
 
 					compute-cb@6 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <6>;
+						reg = <0x0 0x6 0x0 0x0>;
 						iommus = <&apps_smmu 0x1966 0x0>,
 							 <&apps_smmu 0x0c06 0x20>,
 							 <&apps_smmu 0x0c46 0x0>,
@@ -6385,7 +6389,7 @@ compute-cb@6 {
 
 					compute-cb@7 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <7>;
+						reg = <0x0 0x7 0x0 0x0>;
 						iommus = <&apps_smmu 0x1967 0x0>,
 							 <&apps_smmu 0x0c27 0x0>,
 							 <&apps_smmu 0x0c07 0x40>,
@@ -6395,7 +6399,7 @@ compute-cb@7 {
 
 					compute-cb@8 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <8>;
+						reg = <0x0 0x8 0x0 0x0>;
 						iommus = <&apps_smmu 0x1968 0x0>,
 							 <&apps_smmu 0x0c08 0x20>,
 							 <&apps_smmu 0x0c48 0x0>,
@@ -6405,7 +6409,7 @@ compute-cb@8 {
 
 					compute-cb@12 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <12>;
+						reg = <0x0 0xc 0x0 0x0>;
 						iommus = <&apps_smmu 0x196c 0x0>,
 							 <&apps_smmu 0x0c2c 0x00>,
 							 <&apps_smmu 0x0c0c 0x40>,
@@ -6415,12 +6419,13 @@ compute-cb@12 {
 
 					compute-cb@13 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <13>;
+						reg = <0x0 0xd 0x0 0x0>;
 						iommus = <&apps_smmu 0x196d 0x0>,
 							 <&apps_smmu 0x0c0d 0x40>,
 							 <&apps_smmu 0x0c2e 0x0>,
 							 <&apps_smmu 0x0c2d 0x0>,
 							 <&apps_smmu 0x19cd 0x0>;
+						iommu-ranges = <0x4 0x0 0xfc 0x0>;
 						dma-coherent;
 					};
 				};

-- 
2.34.1

[PATCH v2 2/2] arm64: dts: qcom: glymur: add CDSP FastRPC extended context bank

[Vinayak Katoch]

Wire up compute-cb@12 as the dedicated extended IOVA context bank by
adding iommu-ranges = <0x4 0x0 0xfc 0x0>, restricting allocations to
the [16 GiB, ~1 TiB) window. This allows large CDSP buffers to be
mapped beyond the standard 34-bit limit.

Bump #address-cells and #size-cells to <2> on the fastrpc and glink
ancestor nodes to accommodate 64-bit iommu-ranges values, and update
all compute-cb reg entries to the four-cell format accordingly.

Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur.dtsi | 31 ++++++++++++++++++-------------
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 65a398c0a992..556867fbf197 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -8462,6 +8462,8 @@ remoteproc_cdsp: remoteproc@32300000 {
 			qcom,qmp = <&aoss_qmp>;
 			qcom,smem-states = <&smp2p_cdsp_out 0>;
 			qcom,smem-state-names = "stop";
+			#address-cells = <2>;
+			#size-cells = <2>;
 
 			status = "disabled";
 
@@ -8473,17 +8475,19 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
 						IPCC_MPROC_SIGNAL_GLINK_QMP>;
 				qcom,remote-pid = <5>;
 				label = "cdsp";
+				#address-cells = <2>;
+				#size-cells = <2>;
 
 				fastrpc {
 					compatible = "qcom,glymur-fastrpc", "qcom,kaanapali-fastrpc";
 					qcom,glink-channels = "fastrpcglink-apps-dsp";
 					label = "cdsp";
-					#address-cells = <1>;
-					#size-cells = <0>;
+					#address-cells = <2>;
+					#size-cells = <2>;
 
 					compute-cb@1 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <1>;
+						reg = <0x0 0x1 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x2401 0x440>,
 							 <&apps_smmu 0x1961 0x0>,
@@ -8493,7 +8497,7 @@ compute-cb@1 {
 
 					compute-cb@2 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <2>;
+						reg = <0x0 0x2 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x2402 0x440>,
 							 <&apps_smmu 0x1962 0x0>,
@@ -8503,7 +8507,7 @@ compute-cb@2 {
 
 					compute-cb@3 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <3>;
+						reg = <0x0 0x3 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x2403 0x440>,
 							 <&apps_smmu 0x1963 0x0>,
@@ -8513,7 +8517,7 @@ compute-cb@3 {
 
 					compute-cb@4 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <4>;
+						reg = <0x0 0x4 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x2404 0x440>,
 							 <&apps_smmu 0x1964 0x0>,
@@ -8523,7 +8527,7 @@ compute-cb@4 {
 
 					compute-cb@5 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <5>;
+						reg = <0x0 0x5 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x2405 0x440>,
 							 <&apps_smmu 0x1965 0x0>,
@@ -8533,7 +8537,7 @@ compute-cb@5 {
 
 					compute-cb@6 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <6>;
+						reg = <0x0 0x6 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x2406 0x440>,
 							 <&apps_smmu 0x1966 0x0>,
@@ -8543,7 +8547,7 @@ compute-cb@6 {
 
 					compute-cb@7 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <7>;
+						reg = <0x0 0x7 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x2407 0x440>,
 							 <&apps_smmu 0x1967 0x0>,
@@ -8553,7 +8557,7 @@ compute-cb@7 {
 
 					compute-cb@8 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <8>;
+						reg = <0x0 0x8 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x2408 0x440>,
 							 <&apps_smmu 0x1968 0x0>,
@@ -8565,7 +8569,7 @@ compute-cb@8 {
 
 					compute-cb@10 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <10>;
+						reg = <0x0 0xa 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x240c 0x440>,
 							 <&apps_smmu 0x196c 0x0>,
@@ -8575,7 +8579,7 @@ compute-cb@10 {
 
 					compute-cb@11 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <11>;
+						reg = <0x0 0xb 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x240d 0x440>,
 							 <&apps_smmu 0x196d 0x0>,
@@ -8585,11 +8589,12 @@ compute-cb@11 {
 
 					compute-cb@12 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <12>;
+						reg = <0x0 0xc 0x0 0x0>;
 
 						iommus = <&apps_smmu 0x240e 0x440>,
 							 <&apps_smmu 0x196e 0x0>,
 							 <&apps_smmu 0x19ce 0x0>;
+						iommu-ranges = <0x4 0x0 0xfc 0x0>;
 						dma-coherent;
 					};
 				};

-- 
2.34.1

Re: [PATCH v2 2/2] arm64: dts: qcom: glymur: add CDSP FastRPC extended context bank

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dma: iommu-ranges property fails to restrict IOVA allocations
- [Low] dt-bindings: unnecessary #address-cells and #size-cells cause DTC warnings
--

commit 62c300467cdba54ac064fbbf7a04d9a00a746896
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

arm64: dts: qcom: glymur: add CDSP FastRPC extended context bank

This commit wires up compute-cb@12 as a dedicated extended IOVA context bank
by adding an iommu-ranges property to restrict allocations to the [16 GiB,
~1 TiB) window. It also updates #address-cells, #size-cells, and the reg
properties to accommodate 64-bit values.

> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index de7c395d9c353..cba22314591f2 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -8370,6 +8370,8 @@ remoteproc_cdsp: remoteproc@32300000 {
>  			qcom,qmp = <&aoss_qmp>;
>  			qcom,smem-states = <&smp2p_cdsp_out 0>;
>  			qcom,smem-state-names = "stop";
> +			#address-cells = <2>;
> +			#size-cells = <2>;

[Severity: Low]
Are these properties necessary here? Device Tree dictates that
#address-cells and #size-cells only affect a node's direct children. Since
glink-edge does not have a reg or ranges property, adding these properties
to its parent is non-functional and triggers avoid_unnecessary_addr_size DTC
warnings. It also violates strict YAML bindings.

>  
>  			status = "disabled";
>  
> @@ -8381,17 +8383,19 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
>  						IPCC_MPROC_SIGNAL_GLINK_QMP>;
>  				qcom,remote-pid = <5>;
>  				label = "cdsp";
> +				#address-cells = <2>;
> +				#size-cells = <2>;

[Severity: Low]
Similar to the remoteproc_cdsp node, could these properties be removed from
the glink-edge node? The fastrpc child node lacks a reg or ranges property,
so these will cause DTC warnings and dtbs_check failures.

[ ... ]

> @@ -8493,11 +8497,12 @@ compute-cb@11 {
>  
>  					compute-cb@12 {
>  						compatible = "qcom,fastrpc-compute-cb";
> -						reg = <12>;
> +						reg = <0x0 0xc 0x0 0x0>;
>  
>  						iommus = <&apps_smmu 0x240e 0x440>,
>  							 <&apps_smmu 0x196e 0x0>,
>  							 <&apps_smmu 0x19ce 0x0>;
> +						iommu-ranges = <0x4 0x0 0xfc 0x0>;

[Severity: High]
Does this property actually restrict IOVA allocations as intended?

The generic Linux DMA and OF subsystems only parse the standard dma-ranges
property to establish IOVA domain geometry.

The fastrpc driver only checks for the presence of iommu-ranges via
of_property_present() to raise the DMA mask to 40 bits, but it never reads
the base address or size values.

Because no lower bound is configured for the IOVA domain, the allocator can
hand out IOVAs starting from 0, potentially causing device faults or memory
corruption if the DSP hardware requires mappings above the 16 GiB boundary.

>  						dma-coherent;
>  					};
>  				};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-extended-mapping-dts-v2-0-fa9e14900313@oss.qualcomm.com?part=2

Re: [PATCH v2 1/2] arm64: dts: qcom: kaanapali: add CDSP FastRPC extended context bank

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dts: qcom: iommu-ranges property is unparsed, failing to restrict IOVA bounds
- [Low] dts: qcom: unit-address mismatch for compute-cb@12 and compute-cb@13
--

commit 1be2c80a69e840e3c302f9de578640a50eb91ac9
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

arm64: dts: qcom: kaanapali: add CDSP FastRPC extended context bank

This commit wires up compute-cb@13 as a dedicated extended IOVA context bank
by adding the iommu-ranges property to restrict allocations. It also bumps
address and size cells to 2 to support 64-bit iommu-ranges, and updates the
compute-cb reg entries accordingly.

> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index 131fd2a16c545..ed5853dd3c510 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi

[ ... ]

> @@ -6112,7 +6116,7 @@ compute-cb@8 {
>  
>  					compute-cb@12 {
>  						compatible = "qcom,fastrpc-compute-cb";
> -						reg = <12>;
> +						reg = <0x0 0xc 0x0 0x0>;

[Severity: Low]
Does the unit-address @12 need to be updated to match the new reg property?

The device tree specification requires the unit-address to exactly match the
first address in the reg property, formatted as hex without the 0x prefix. By
updating the reg address to 0xc but leaving the unit-address as @12, does
this trigger a unit_address_vs_reg dtc compilation warning?

>  						iommus = <&apps_smmu 0x196c 0x0>,
>  							 <&apps_smmu 0x0c2c 0x00>,
>  							 <&apps_smmu 0x0c0c 0x40>,
> @@ -6122,12 +6126,13 @@ compute-cb@12 {
>  
>  					compute-cb@13 {
>  						compatible = "qcom,fastrpc-compute-cb";
> -						reg = <13>;
> +						reg = <0x0 0xd 0x0 0x0>;

[Severity: Low]
Similar to the node above, does the unit-address @13 need to be updated to @d
to match the new reg address of 0xd?

>  						iommus = <&apps_smmu 0x196d 0x0>,
>  							 <&apps_smmu 0x0c0d 0x40>,
>  							 <&apps_smmu 0x0c2e 0x0>,
>  							 <&apps_smmu 0x0c2d 0x0>,
>  							 <&apps_smmu 0x19cd 0x0>;
> +						iommu-ranges = <0x4 0x0 0xfc 0x0>;

[Severity: High]
Does the kernel actually parse these lower bound restrictions?

The commit message states this restricts allocations to the [16 GiB, ~1 TiB)
window. However, the kernel's OF/IOMMU framework exclusively parses
dma-ranges to set up IOVA domain geometry. The custom iommu-ranges property
is never parsed by the core kernel.

Looking at drivers/misc/fastrpc.c, fastrpc_cb_init() only checks for the
presence of iommu-ranges:

	if (of_property_present(dev->of_node, "iommu-ranges"))
		is_extended_cb = true;

Since the driver sets a 40-bit DMA mask based on this presence but completely
ignores the specified lower bound, will the IOMMU IOVA allocator fall back to
the default domain geometry and freely allocate addresses in the [0, 16 GiB)
range instead?

Could this lead to fatal DSP faults or memory overlap if the DSP hardware
expects the allocations strictly in the restricted window?

>  						dma-coherent;
>  					};
>  				};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-extended-mapping-dts-v2-0-fa9e14900313@oss.qualcomm.com?part=1