[PATCH 0/3] arm64: tegra: Add iommu and dma properties for Tegra194 QSPI

[PATCH 0/3] arm64: tegra: Add iommu and dma properties for Tegra194 QSPI

[Aaron Kling via B4 Relay]

The reason for this is to properly support the spi nor chip on the
Jetson Xavier NX module. Prior to this, it would time out on all
transfers and sometimes even trigger a cbb fault, locking up the entire
unit. With this, reading and writing to the flash memory works as
expected.

---
Aaron Kling (3):
      spi: dt-bindings: tegra: Support IOMMU property for Tegra194 QSPI
      spi: dt-bindings: tegra: Support dma-coherent property for QSPI
      arm64: tegra: Add iommu and dma properties for Tegra194 QSPI

 Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml | 6 +++++-
 arch/arm64/boot/dts/nvidia/tegra194.dtsi                        | 8 ++++++++
 2 files changed, 13 insertions(+), 1 deletion(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260515-tegra194-qspi-iommu-e4e4644d5fdf

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

[PATCH 1/3] spi: dt-bindings: tegra: Support IOMMU property for Tegra194 QSPI

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

This is supported via an external dma controller

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
index 909c204b8adf81..62233eb3101aeb 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
@@ -78,7 +78,9 @@ allOf:
         compatible:
           not:
             contains:
-              const: nvidia,tegra234-qspi
+              enum:
+                - nvidia,tegra194-qspi
+                - nvidia,tegra234-qspi
     then:
       properties:
         iommus: false

-- 
2.53.0

[PATCH 2/3] spi: dt-bindings: tegra: Support dma-coherent property for QSPI

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

DMA coherency is supported by at least the Tegra194 and Tegra234
controllers.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
index 62233eb3101aeb..433bca02f86b13 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
@@ -47,6 +47,8 @@ properties:
   iommus:
     maxItems: 1
 
+  dma-coherent: true
+
 patternProperties:
   "@[0-9a-f]+$":
     type: object

-- 
2.53.0

[PATCH 3/3] arm64: tegra: Add iommu and dma properties for Tegra194 QSPI

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

Without iommu and dma enabled, flash storage such as the spi-nor on the
p3668 module times out and cannot complete any transfers.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 1d659454a6f9fe..0e0a20befe9e68 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -923,6 +923,10 @@ spi@3270000 {
 				 <&bpmp TEGRA194_CLK_QSPI0_PM>;
 			clock-names = "qspi", "qspi_out";
 			resets = <&bpmp TEGRA194_RESET_QSPI0>;
+			iommus = <&smmu TEGRA194_SID_GPCDMA_0>;
+			dma-coherent;
+			dmas = <&gpcdma 5>, <&gpcdma 5>;
+			dma-names = "rx", "tx";
 			status = "disabled";
 		};
 
@@ -1013,6 +1017,10 @@ spi@3300000 {
 				 <&bpmp TEGRA194_CLK_QSPI1_PM>;
 			clock-names = "qspi", "qspi_out";
 			resets = <&bpmp TEGRA194_RESET_QSPI1>;
+			iommus = <&smmu TEGRA194_SID_GPCDMA_0>;
+			dma-coherent;
+			dmas = <&gpcdma 6>, <&gpcdma 6>;
+			dma-names = "rx", "tx";
 			status = "disabled";
 		};
 

-- 
2.53.0

Re: [PATCH 1/3] spi: dt-bindings: tegra: Support IOMMU property for Tegra194 QSPI

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incorrectly allowing the `iommus` property on a device node that uses an external DMA controller.
--

commit 7b9b9a70107dbc216f12066e863bde3029e71a0d
Author: Aaron Kling <webgeek1234@gmail.com>

spi: dt-bindings: tegra: Support IOMMU property for Tegra194 QSPI

This commit updates the Tegra210 QSPI device tree binding to allow the
iommus property for the Tegra194 QSPI compatible string. It states that
this is supported via an external DMA controller.

> spi: dt-bindings: tegra: Support IOMMU property for Tegra194 QSPI
>
> This is supported via an external dma controller

If the Tegra194 QSPI controller uses an external DMA controller, the external
DMA controller acts as the bus master while the QSPI controller is a peripheral
slave. Because the iommus property specifies the IOMMU master interfaces for a
device that performs direct memory access, does this property belong on the
external DMA controller's node rather than the QSPI controller's node?

> diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
> --- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
> +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
> @@ -78,7 +78,9 @@ allOf:
>          compatible:
>            not:
>              contains:
> -              const: nvidia,tegra234-qspi
> +              enum:
> +                - nvidia,tegra194-qspi
> +                - nvidia,tegra234-qspi
>      then:
>        properties:
>          iommus: false

Allowing the iommus property on the QSPI node here appears to misrepresent
the hardware architecture for an external DMA topology. If the operating
system attempts to attach an IOMMU domain to the QSPI device based on
this binding, could the actual DMA transfers fault due to the DMA controller
itself not being mapped?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515-tegra194-qspi-iommu-v1-0-57dfb63cd3d6@gmail.com?part=1

Re: [PATCH 2/3] spi: dt-bindings: tegra: Support dma-coherent property for QSPI

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `dma-coherent` property is allowed globally for all SoC variants, including older ones that lack DMA coherency support.
--

commit 65a20c2287e15ca3b52c5785b3e048bc7401f80b
Author: Aaron Kling <webgeek1234@gmail.com>

spi: dt-bindings: tegra: Support dma-coherent property for QSPI

This commit adds the dma-coherent property to the Tegra QSPI device tree
binding, noting that it is supported by at least the Tegra194 and Tegra234
controllers.

> diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
> index 62233eb3101ae..433bca02f86b1 100644
> --- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
> +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
> @@ -47,6 +47,8 @@ properties:
>    iommus:
>      maxItems: 1
>  
> +  dma-coherent: true
> +

By adding this unconditionally to the top-level properties block, does the
schema now permit this property for all hardware variants?

If a device tree incorrectly applies dma-coherent to an older, non-coherent
generation like Tegra210 or Tegra186, it appears it would silently pass
validation.

Could this be constrained via an if-then block in allOf to set
dma-coherent: false for unsupported variants, similar to how the iommus
property is handled in this file?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515-tegra194-qspi-iommu-v1-0-57dfb63cd3d6@gmail.com?part=2

Re: [PATCH 3/3] arm64: tegra: Add iommu and dma properties for Tegra194 QSPI

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware misrepresentation: QSPI node falsely claims GPCDMA's SMMU Stream ID to mask a driver bug
--

commit 5a99acb609c512098a594cb6c335a984b6c04380
Author: Aaron Kling <webgeek1234@gmail.com>

arm64: tegra: Add iommu and dma properties for Tegra194 QSPI

This commit adds DMA and IOMMU properties to the QSPI controller nodes for
Tegra194. The commit message indicates these are required to prevent flash
storage transfers from timing out.

> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index 1d659454a6f9f..0e0a20befe9e6 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -923,6 +923,10 @@ spi@3270000 {
>  				 <&bpmp TEGRA194_CLK_QSPI0_PM>;
>  			clock-names = "qspi", "qspi_out";
>  			resets = <&bpmp TEGRA194_RESET_QSPI0>;
> +			iommus = <&smmu TEGRA194_SID_GPCDMA_0>;

Does assigning the GPCDMA's Stream ID to the QSPI node misrepresent the
hardware topology?

TEGRA194_SID_GPCDMA_0 physically belongs to the external GPCDMA controller,
which is the actual bus master performing the DMA transfers. Device trees
must strictly describe hardware. 

It appears this configuration might be masking a driver bug in
drivers/spi/spi-tegra210-quad.c, where tegra_qspi_dma_map_xfer() maps buffers
against the QSPI device rather than the DMA engine's device pointer. Faking
the same Stream ID places both devices in the same SMMU group, which avoids
translation faults but breaks IOMMU isolation.

Should the driver be fixed to map memory using the DMA provider's device
pointer instead of adding the iommus and dma-coherent properties to the QSPI
nodes?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515-tegra194-qspi-iommu-v1-0-57dfb63cd3d6@gmail.com?part=3