glitch in spi-imx rxready irq assertion?

[Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>]

Hello,

I currently try to pin down a problem reported by a customer. They do
repeated read/write operations to an MRAM connected via SPI to an i.MX6
running Linux 4.14 with a few spi-Patches backported (
e697271c4e29 ("spi: imx: add a device specific prepare_message callback")
00b80ac93553 ("spi: imx: mx51-ecspi: Move some initialisation to prepare_message hook.")
). We only use PIO because of some problems we saw disappearing when DMA
is disabled.

Sometimes the machine logs an I/O error and after that hangs, sometimes
the whole machine is not responsive any more (not entirely sure this is
related).

Applying some tracing I see:

After a big transfer (4096 bytes) that completed successfully another 4
bytes are written to the hardware. Then the irq routine[1] is called,
->rx_available returns false, ->count is zero and ->txfifo is still
non-zero. So the irq triggered because the TX-fifo was empty but there
wasn't yet data available to receive and so the RR irq got enabled. The
RR-irq doesn't trigger during the next two seconds however.

Does this ring a bell for you? Is there maybe a glitch that the RR-irq
doesn't trigger in such a case?

The obvious workaround would be to enable RR (or RDR) before starting to
write data to the FIFO.
The problem isn't easy to reproduce and I'm unsure if I can resolve the
problem as fixed when it doesn't reappear after that change. So some
input from your side that confirms my suspicion would be great.

I'd also make sure that no FIFO overflow happened (using the
RO interrupt) but I don't expect any relevant insights here.

Best regards
Uwe

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-imx.c?h=v4.14#n951

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |