One limitation of the driver is that hardware only raises an interrupt if the RX queue contains at least 4 characters, so fewer than 4 characters in the queue may result in data never being received.

Do you not receive the SSPRTINTR interrupt?

In D45211#1036945, @andrew wrote:

One limitation of the driver is that hardware only raises an interrupt if the RX queue contains at least 4 characters, so fewer than 4 characters in the queue may result in data never being received.

Do you not receive the SSPRTINTR interrupt?

Nope, and it's documented in the reference (DDI0194H):

3.4.1
SSPRXINTR
The receive interrupt is asserted when there are four or more valid entries in the receive FIFO.

In D45211#1036969, @jhibbits wrote:

3.4.1
SSPRXINTR
The receive interrupt is asserted when there are four or more valid entries in the receive FIFO.

That's a different interrupt, see 3.4.4 SSPRTINTR of the same document.

In D45211#1036980, @andrew wrote:

In D45211#1036969, @jhibbits wrote:

3.4.1
SSPRXINTR
The receive interrupt is asserted when there are four or more valid entries in the receive FIFO.

That's a different interrupt, see 3.4.4 SSPRTINTR of the same document.

Ah, sorry, I had misread. Apparently I don't get the SSPRTINTR on the device I have, as it seems to time out (2 second timeout) on 3-byte messages, and the interrupt is enabled. Maybe it's an issue with my particular device?

Do you need interrupts in this driver? It looks like Linux only uses them when using DMA to transfer data to/from the device.

In D45211#1040937, @andrew wrote:

Do you need interrupts in this driver? It looks like Linux only uses them when using DMA to transfer data to/from the device.

Maybe not, but this is consistent with every other SPI driver in the tree.