2008-05-05 04:28:22 SPI transfer NOW (if possible)

Hans Eklund (SWEDEN)

Message: 55483

Ive been around this issue before, at moderate load of the system we see a heavy spread in the time it takes to execute a single and short spi_sync() with only a few bytes to transfer, sometimes not returning after 10-20ms or worse.

Im in need of making sure a short spi message to an FPGA unit get sent just within a few milliseconds, hardly a real-time problem, i just need to reconfiugure a camera running at 20-30 fps now and then. So in between the frames i need to some SPI. Raising FPS to 50-60 would require the SPI part of the code to execute(and return with success) even faster. There is an algorithm that need to be run on each frame also. But with the spi framework it can fail at times. I believe this is the source of the problem:

1) compose a message of two transfers, say 3 bytes TX and 3 byte RX.

2) call spi_sync which in turn cann spi_async and the thread will wait for completion.

3) spi_async will call spi->master->transfer that do queue_work on the pump_message() function.

4) once the message is processed, the message pump schedules the first transfer...

5) once the transfer is scheduled, the data is sent over the SPI bus and the next transfer is tasklet_schedules once again(either from dma interrupt or end of pio).

All the tasklet scheduling is really taking a toll here. Who knows what house keeping business would take place between each transfer. I would like to skip the tasklet_schedule latencies here and get to the fun part which is in 5) and also skipping the scheduling the next transfers and just call the transfer part directly(if possible). Im imagining this function could be allow to execute if

- there is only once spi protocol driver loded

- or the message queue is emtpy.

If a DMA transfer was intended we cant cut the DMA complete to workqueue latency, we will have to live with that, but the tasklet_schedule()'s could be cut if the circumstances are right. A short PIO transfer could be executed right away and return.

Im scetching on combining the transfer() and pump_messages() function (all found in spi_bfin5xx.c) into a single function call chain and add an option at the end of pump_transfers() to run it again directly recursiveley and not schedule it self as a tasklet.

Is this stupid? Could it be done? Would there be an easier way to make this happen? I would really like to see a function very soon that could send 10 bytes of SPI data at 20Mhz in < 1ms if the bus is idle!

/Hans

(edit: clarify, formatting)

QuoteReplyEditDelete

2008-05-05 07:30:31 Re: SPI transfer NOW (if possible)

Hans Eklund (SWEDEN)

Message: 55496

Done and... well half way done..

Implemented bfin_direct_transfer in the blackfin spi master.. a small hack of copy-pasted code to avoid tasklets and workqueues.

Test module uses it and do a 4 byte TX transfer only, compared to spi_sync(), No other busy threads on the system: