Code size report:

Reference:  esp32/mpconfigport: Enable Zcmp opcodes for ESP32P4. [6341258]
Comparison: rp2/machine_spi: Don't use DMA for SPI transfers if PSRAM is enabled. [merge of 403b109]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Is this a bug or a known limitation? If the bus arbitration for PSRAM can fail irretrievably in the face of concurrent access by two DMA channels, the fault will eventually occur in user code. In this case disabling DMA in the SPI driver is a workround rather than a fix. If, rather than a bug, there is an inherent limit on DMA data rates it should be documented.

Force pushed 403b109, which only disables DMA transfers if PSRAM is enabled. @dpgeorge Please have a look. Haven't tested yet, don't have hardware with me right now.

Is this a bug or a known limitation?

The fact that DMA transfers to/from PSRAM can stall other DMA channels is a known limitation. Section 4.4.3 of the RP2350 datasheet states this pretty clearly in the second paragraph:

...QMI serial transfers force lengthy bus stalls on the DMA... stalling the DMA prevents any other active DMA channels from making progress during this time, slowing overall DMA throughput.

However, the current MicroPython SPI implementation results in a bug where the processor can get stuck in an infinite loop, because it does nothing to consider the above limitation. IMO, it should at least do something to guarantee that it can't get stuck in an infinite loop.

In this case disabling DMA in the SPI driver is a workround rather than a fix.

Yes, outright disabling DMA transfers is certainly a workaround. Perhaps an alternative fix could be something like the following?

         dma_start_channel_mask((1u << chan_rx) | (1u << chan_tx));
-        dma_channel_wait_for_finish_blocking(chan_rx);
         dma_channel_wait_for_finish_blocking(chan_tx);

+        // Wait for SPI to finish, and all data to be received by RX DMA
+        while (spi_is_busy(self->spi_inst) || spi_is_readable(self->spi_inst)) {
+        }
+
+        // If RX DMA still has transfers pending, raise an error
+        if (dma_channel_hw_addr(chan_rx)->transfer_count) {
+            mp_raise_OSError(MP_EIO);
+        }
    }