msperl

In the meantime I have figured out a test for most use-cases (CS-polarity and 3Wire) this only leaves LoSSI open.

Note that there is a major issue with latencies of interrupts - need to document this. Obviously it is more performant with a RPI2, but still far from perfect.

@popcornmix: why not handle parts of the USB interrupt via RTOS - from what I have looked at, it looks as if the VideoCore has a fully vectored interrupt handler,...

Another observation: In general there are 2 interrupts that happen every 8000.9us on a VERY regular basis. - the first one takes 22.45us - the second takes 18.15us - time...

Note: here the patch with the instrumentation: https://github.com/raspberrypi/linux/compare/rpi-3.18.y...msperl:rpi-3.18.y-irq_instrumented obviously you also need a fast logic-analyzer to get those measurements...

A few of those patches have been in the spi tree - which shall go into linux-next, so we are moving forward...

Status is right now: I can run 4 distinct devices on my RPI now using arbitrary GPIOs as CS. 2x mcp2515 1x fb_st7735r 1x enc28j60 The only thing I have...

the following commits: ddb9376c836548263e6744bf7636181589b06d16 - fix all checkpath --strict messages 066aa208a57ff914dd56540830f69b6a685fd700 - allow arbitrary GPIO to act as SPI-chip_select 253e15ed751a96c57aeebe3bee5ca633eba8dd87 - fill/drain SPI-fifo as much as possible are now in:...

next step: - avoid initial irq to transmit data - this reduces delays by 4us - implement polling for short transfers - an interrupt takes about 8-12us from start to...

I guess that DMA will be the 3rd in the list now - to start assuming that we have spi_message.is_dma_mapped=true and not relying on can_dma functionality... @notro: Maybe you can...