On Wed, May 20, 2026 at 12:29:49PM -0500, Aaron Kling wrote:
> On Wed, May 20, 2026 at 6:49 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Fri, May 15, 2026 at 03:35:29PM -0500, Aaron Kling via B4 Relay wrote:
> > > 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";
> >
> > dmas and dma-names are the only properties that you should need here.
> 
> This is where I started and it didn't work. Without the iommu
> properties, I get endless mmu faults upon accessing the qspi flash
> device:
> 
> [   62.313833] tegra-mc 2c00000.memory-controller: axisw: secure write
> @0x00000003ffffff00: VPR violation ((null))
> [   62.324542] arm-smmu 12000000.iommu: Unhandled context fault:
> fsr=0x402, iova=0xcd21d000, fsynr=0x80012, cbfrsynra=0x820, cb=1
> 
> I know downstream kernels aren't always (normally...) the arbiter of
> sanity, but I did pull these from the Nvidia downstream 5.10 kernel,
> which is where Nvidia was starting to try to align with mainline
> paradigms. All of these properties are set there.
> 
> If the qspi node isn't supposed to set iommu directly, then there's a
> larger problem here that I don't even know where to begin to look
> into. All I can say is that dma fails with faults if they are not set
> and works when they are.

I think this is a problem similar to what we experienced with I2C a
little while ago, which we fixed like so:

    cdbf26251d3b ("i2c: tegra: Allocate DMA memory for DMA engine")

There's another patch currently under review that tries to simplify this
further using new support from the dmaengine subsystem:

    https://patchwork.ozlabs.org/project/linux-tegra/patch/20260518114013.62065-2-akhilrajeev@nvidia.com/

Doing something analogous for QSPI should fix this.

Thierry