Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml | 6 +++++- arch/arm64/boot/dts/nvidia/tegra194.dtsi | 8 ++++++++ 2 files changed, 13 insertions(+), 1 deletion(-)
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>
On 15/05/2026 21:35, Aaron Kling via B4 Relay wrote: > 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. What kernel's do you see this on? With the latest mainline/-next I do see ... tegra-qspi 3270000.spi: cannot use DMA: -19 tegra-qspi 3270000.spi: falling back to PIO But I don't see the crash. However, on linux-6.1.y I do see the crash ... tegra-qspi 3270000.spi: cannot use DMA: -19 tegra-qspi 3270000.spi: falling back to PIO tegra-qspi 3270000.spi: transfer timeout tegra-qspi 3270000.spi: error in transfer, fifo status 0x20400006 CPU:0, Error: cbb-noc@2300000, irq=15 So I believe recent upstream changes in the Tegra210 QSPI driver have fixed this. This series does fix the issue on linux-6.1.y but I believe that is because this is really enabling DMA support and so PIO is still broken. Ideally, PIO should work if DMA support is missing in device-tree. IMO this series simply enables DMA support. May be we should clarify this in the commit message, but otherwise, I am fine with these changes. Jon -- nvpublic
On 19/05/2026 15:43, Jon Hunter wrote: > > On 15/05/2026 21:35, Aaron Kling via B4 Relay wrote: >> 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. > > What kernel's do you see this on? With the latest mainline/-next I do > see ... > > tegra-qspi 3270000.spi: cannot use DMA: -19 > tegra-qspi 3270000.spi: falling back to PIO > > But I don't see the crash. However, on linux-6.1.y I do see the crash ... > > tegra-qspi 3270000.spi: cannot use DMA: -19 > tegra-qspi 3270000.spi: falling back to PIO > tegra-qspi 3270000.spi: transfer timeout > tegra-qspi 3270000.spi: error in transfer, fifo status 0x20400006 > CPU:0, Error: cbb-noc@2300000, irq=15 > > So I believe recent upstream changes in the Tegra210 QSPI driver have > fixed this. > > This series does fix the issue on linux-6.1.y but I believe that is > because this is really enabling DMA support and so PIO is still broken. > Ideally, PIO should work if DMA support is missing in device-tree. > > IMO this series simply enables DMA support. May be we should clarify > this in the commit message, but otherwise, I am fine with these changes. BTW, that said. This is a much simpler way to avoid the hang on earlier kernels. So I would be happy to get this merged and backport to stable as a fix. Again may be we just need to clarify this a bit more in the commit message. Jon -- nvpublic
On Tue, May 19, 2026 at 10:50 AM Jon Hunter <jonathanh@nvidia.com> wrote: > > > On 19/05/2026 15:43, Jon Hunter wrote: > > > > On 15/05/2026 21:35, Aaron Kling via B4 Relay wrote: > >> 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. > > > > What kernel's do you see this on? With the latest mainline/-next I do > > see ... > > > > tegra-qspi 3270000.spi: cannot use DMA: -19 > > tegra-qspi 3270000.spi: falling back to PIO > > > > But I don't see the crash. However, on linux-6.1.y I do see the crash ... > > > > tegra-qspi 3270000.spi: cannot use DMA: -19 > > tegra-qspi 3270000.spi: falling back to PIO > > tegra-qspi 3270000.spi: transfer timeout > > tegra-qspi 3270000.spi: error in transfer, fifo status 0x20400006 > > CPU:0, Error: cbb-noc@2300000, irq=15 > > > > So I believe recent upstream changes in the Tegra210 QSPI driver have > > fixed this. > > > > This series does fix the issue on linux-6.1.y but I believe that is > > because this is really enabling DMA support and so PIO is still broken. > > Ideally, PIO should work if DMA support is missing in device-tree. > > > > IMO this series simply enables DMA support. May be we should clarify > > this in the commit message, but otherwise, I am fine with these changes. > > BTW, that said. This is a much simpler way to avoid the hang on earlier > kernels. So I would be happy to get this merged and backport to stable > as a fix. Again may be we just need to clarify this a bit more in the > commit message. I could update the commit message to be more like 'Enable DMA support for Tegra194 QSPI', sure. The primary kernel version I'm working on currently is 6.18, specifically googles android common kernel fork of it. I also replicated the issue on 6.12 and android-mainline which is currently 7.0-ish. I was not normally seeing issues on boot, though I think I did hit that a couple times when jumping around versions. Where I had trouble was active use of the flash chip, like read/writing the slot metadata for a/b support or writing the flash for inline bootloader updates. The issue wasn't always triggering a cbb panic, but it was (almost?) always timing out and failing to read or write the flash chip. Aaron
On 19/05/2026 17:48, Aaron Kling wrote: ... >> BTW, that said. This is a much simpler way to avoid the hang on earlier >> kernels. So I would be happy to get this merged and backport to stable >> as a fix. Again may be we just need to clarify this a bit more in the >> commit message. > > I could update the commit message to be more like 'Enable DMA support > for Tegra194 QSPI', sure. We should still describe in the commit message that this is also prevent a hang/crash from occurring that is being observed with PIO mode to give the full picture. Jon -- nvpublic
On 19/05/2026 17:48, Aaron Kling wrote: ... > I could update the commit message to be more like 'Enable DMA support > for Tegra194 QSPI', sure. Thanks. > The primary kernel version I'm working on currently is 6.18, > specifically googles android common kernel fork of it. I also > replicated the issue on 6.12 and android-mainline which is currently > 7.0-ish. So I also observed issues with Linux v6.18. However, Linux v7.0 is working fine for me. > I was not normally seeing issues on boot, though I think I did hit > that a couple times when jumping around versions. Where I had trouble > was active use of the flash chip, like read/writing the slot metadata > for a/b support or writing the flash for inline bootloader updates. > The issue wasn't always triggering a cbb panic, but it was (almost?) > always timing out and failing to read or write the flash chip. OK, then you are doing more significant testing that I am. I was just seeing issues on boot, but with Linux v7.0 I no longer see issues on boot. Jon -- nvpublic
© 2016 - 2026 Red Hat, Inc.