Hi,
we are currently debugging an issue with the AXI SPI Engine and wanted to ask if this behavior is known or if anyone has seen something similar.
At low SPI clock frequencies (~2–3 MHz) we are seeing misconfiguration of an ADC (in our case AD7768-1) during probe.
The issue seems to be related to the first SPI transfer after spi_engine_setup().
Suspected behavior
From our debugging, it looks like:
- spi_engine_setup() issues SYNC commands and polls SYNC_ID
- However, the corresponding SYNC interrupt pending bit is not cleared
- When the first real transfer is started:
- INT_SYNC gets enabled
- a stale pending SYNC IRQ fires immediately
- The transfer is then marked as complete before the hardware actually finished
This leads to follow-up transfers starting while the FPGA is still busy.
Sequential flow of the bug
spi_engine_setup()
├─ writel SYNC(0) → CMD FIFO
├─ writel CS_INV → CMD FIFO
├─ writel ASSERT → CMD FIFO
└─ writel SYNC(1) → CMD FIFO
FPGA executes all, sets SYNC_ID = 1
INT_PENDING[SYNC] = 1 ← remains set, NOT cleared
readl_relaxed_poll_timeout(SYNC_ID == 1) ← polled, no IRQ used
return 0
spi_engine_transfer_one_message() ← first real transfer
├─ writes CMD/TX FIFOs
├─ INT_ENABLE |= INT_SYNC ← CRITICAL: stale pending fires immediately
└─ wait_for_completion_timeout()
↑
spi_engine_irq():
pending = INT_PENDING → INT_SYNC set ✓
completed_id = SYNC_ID = 1 (leftover from setup!)
completed_id == AXI_SPI_ENGINE_CUR_MSG_SYNC_ID → TRUE
msg->status = 0
complete(&msg_complete) ← premature! FPGA still executing
↓
returns success
FPGA may still be running the transfer
When it becomes a problem
This is especially visible when the driver performs dense initialization sequences, e.g.:
- multiple regmap_write()
- followed by regmap_update_bits() (read-modify-write)
in that case:
- the read may return a stale value
- resulting in incorrect register configuration
We could reproduce this reliably in the ad7768-1 driver during probe.
The critical path is:
ad7768_configure_dig_fil()
└─ regmap_write(AD7768_REG_DIGITAL_FILTER) ← Transfer 1 → stale IRQ fires here
complete() called early, FPGA still busy
ad7768_set_freq()
└─ ad7768_set_mclk_div()
└─ regmap_update_bits(AD7768_REG_POWER_CLOCK)
└─ regmap_read(AD7768_REG_POWER_CLOCK) ← Transfer 2 (read)
FPGA still busy with Transfer 1
→ read returns wrong/stale value
└─ regmap_write(AD7768_REG_POWER_CLOCK, wrong_mask) ← Transfer 3Why it depends on SPI frequency
- At low SPI clock (~2–3 MHz) the timing window is large enough → issue reproducible
- At higher SPI clock → issue becomes hard or impossible to trigger
Questions
- Is it expected that SYNC events from spi_engine_setup() can still be pending when the first runtime transfer starts?
- Should the driver explicitly clear INT_PENDING[SYNC] after the polled SYNC?
- Has anyone seen similar behavior at low SPI clock rates?
Thanks in advance!
