spidev transfer timeout on Pi 5 with transfers > 64.

[makermelissa]

Describe the bug

I am writing some code in c and am having spidev timeouts on the Pi 5. The same code runs fine on the Pi 4. The first spidev transfer is fine, but subsequent transfers result in timeout errors (despite it successfully transferring), which produces a much slower transfer.

Steps to reproduce the behaviour

1. Install Adafruit Snake Eyes Bonnet
2. Install Raspberry Pi OS 64-bit bookworm Desktop on the Pi 5
3. Update the system
4. Follow directions in https://github.com/makermelissa/Pi_Eyes/blob/wayland-update/README.md to install dependencies
5. Build following same instructions

Device (s)

Raspberry Pi 5

System

Raspberry Pi reference 2023-12-05
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 70cd6f2a1e34d07f5cba7047aea5b92457372e05, stage4

2024/01/24 12:16:01
Copyright (c) 2012 Broadcom
version 1aeae380 (release) (embedded)

Linux raspberrypi 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux

Logs

These message repeat in dmesg:
[ 1829.452018] spidev spi0.0: DMA transaction timed out
[ 1829.452018] spidev spi1.2: DMA transaction timed out
[ 1829.452022] spidev spi0.0: SPI transfer failed: -110
[ 1829.452024] spidev spi1.2: SPI transfer failed: -110
[ 1829.452035] spi_master spi0: failed to transfer one message from queue
[ 1829.452035] spi_master spi1: failed to transfer one message from queue
[ 1829.452037] spi_master spi1: noqueue transfer failed
[ 1829.452038] spi_master spi0: noqueue transfer failed

Additional context

Not 100% sure my code is not the issue, but kind of odd it works fine on Pi 4, but not Pi 5.

[makermelissa]

This may be a duplicate of #5858.

[makermelissa]

Setting transfers to 64 bytes or less fixes the timeout issue, but still quite slow.

[makermelissa]

Perhaps #5696 has popped back up or maybe it's not part of the regular release cycle yet.

[pelwell]

I think this is caused by a bug in the DMA driver that causes the interrupt-enable bit to be cleared. It is caused by a lack of atomicity, and triggered by having transfers submitted on multiple channels simultaneously.

#6044 should be a fix. By the time you read this (a.k.a. any time after 10:40 GMT on the 15th) you'll be able to install a 6.6 kernel with the fix by running sudo rpi-update pulls/6044.

[pelwell]

And yes, I think this is effectively a dup of #5858/#5865.

[makermelissa]

Thanks. Yes, the fix worked.

[makermelissa]

Ok, after further testing, I think it's not quite working correctly. I am trying to use both spidev0.0 and spidev1.2 in my code. With the update, the clock signal from spidev1.2 doesn't seem to be working anymore. Like there's tons of activity on MOSI, but SCLK is barely pulsing.

[pelwell]

What clock rates are you using?

[makermelissa]

80 MHz. I could try slower if you think that would help, but the same code runs fine on a Pi 4 at that clock rate.

[pelwell]

And in which directions? Try and help me reproduce your setup.

[makermelissa]

Pretty much all output. I'm writing to 2 ST7789 displays.

[pelwell]

A few things:

1. The SPI controllers are clocked off clk_sys (200MHz), using an even divisor. This means that your request for 80MHz actually translates to 50MHz. You would have had more flexibility on Pi 4 where the clock is an even divisor of the VPU/core clock, but there the core clock is prone to changing with the ARM clock.
2. With some combinations of transmits and receives I get RX FIFO overflows:

   $ dmesg -l err
   [12461.687616] dma dma2chan3: dma2chan3 is non-idle!
   [12461.889989] spidev spi1.2: DMA transaction timed out
   [12461.889993] spidev spi1.2: SPI transfer failed: -110
   [12461.890003] spi_master spi1: failed to transfer one message from queue
   [12461.890006] spi_master spi1: noqueue transfer failed
   

   What kernel messages do you get?

[makermelissa]

1. Hmm, ok. I tried 50MHz and it didn't change anything.
2. No error messages at all. It just doesn't work.