spi_bcm2835situation

Facts

• Uses/implements:
  • makes use of the new SPI-Framework which results in smaller code-size
  • interrupt handler
  • misses LoSSI/9Bit transfers
  • implements as per "BCM2834 ARM Peripherals" this includes
    • recommendations for filling FIFOs (16bytes then 12) as per 10.6.2/Page 158
    • recommendations for CLK to be a power of 2 - as per 10.5 CLK-Register/Page 156
  • limited to 2/3 SPI devices - no arbitrary GPIO as CS support
• Bugs:
  • Inverted CS does not work correctly if there are 2 or more devices

Typical transfer pattern on the bus

these have the "gpio-timing-instrumentation" enabled and were run on a RPI2 similar/worse pattern happen on a RPI1

Note also that there are channels:

• 4 - CAN_INT - the CAN interrupt signaling a message has arrived
• 5 - D24 - work_run - inside the work-tasklet (potentially sleeping)
• 8 - D23 - trans_wait - waiting on completion inside of transmit code
• 9 - D22 - spi_int - inside the SPI interrupt
• 10 - D18 - mcp-int - inside the interrupt handler of the mcp2515
• 11 - D17 - mcpcompl - inside one of the mcp2515 completion routines

default code

Issues observed:

• Transfers take 10x as long as necessary (for a 1 byte transfer)
• 3us are typically between CS down and the first byte getting sent
  • this is mostly due to the fact that the interrupt handler takes so long to start and push data into the fifo
• also we see lots of WAIT for completions (in the case of multiple transfers for a single transfer like write X then read Y)

Improved startup code prefilling FIFO

Issues observed:

• the "starting" gap has gone away, but it still leaves us with:
  • Transfer finished and Interrupt handler running
  • Interrupt-handler waking up the completion and the workqueue resuming its work

improved interrupt code for handling multiple transfers as one