On Sat, Nov 07, 2020 at 05:13:52PM +0900, Damien Le Moal wrote: > With boards that have slow interrupts context switch, and a fast device > connected to a spi master, e.g. an SD card through mmc-spi, using > dw_spi_poll_transfer() intead of the regular interrupt based > dw_spi_transfer_handler() function is more efficient and can avoid a lot > of RX FIFO overflow errors while keeping the device SPI frequency > reasonnably high (for speed). Introduce the "polling" device tree > property to allow requesting polled processing of transfer depending on > the connected device while keeping the spi master interrupts property > unschanged. E.g. device trees such as: This isn't something that looks like it should be configured via DT as a separate property, this is more of a tuning property as far as I can see - even on the same hardware there might be cases where people prefer to keep using interrupts but for example allow transfers to stall while waiting for the interrupt controller giving lower throughput but more CPU cycles available for other things. Unfortunately we don't have any information about how much interrupt latency we should expect which makes this a bit annoying. I do see that there's already some existing attempt in the DMA code to tune burst sizes to avoid FIFO overflows - it looks like the hardware is doing something unusual and possibly unfortunate here though I've never looked at it so I'm not sure exactly what is going on there but perhaps ther's some tuning that can be done in there? TBH I'm not clear what the failure mode is where we need software to service interrupts promptly in the middle of a DMA transfer in the first place, that seems really strange.
Attachment:
signature.asc
Description: PGP signature
