What is the difference interrupt based and poll based SPI transaction

Question

I have some doubts regarding SPI communication protocol.On my architecture there is a SPI communication link between processor and CPLD device.I wanted to write to one of the CPLD register.

I am planning to write CPLd LKM which would pass address of CPLD register and value to spi linux core using calls like spi_sync.

So Do I need to consider processor as master and CPLD device as slave?

Also,would want to know what it mean by interrupt based and poll based SPI transaction and why poll based transaction is advisable at boot time?

Answer 1

So Do I need to consider processor as master and CPLD device as slave?

The SPI controller attached to the CPU would presumably be the SPI master (although there are SoCs with SPI controllers that can operate either in master or slave mode).
The SPI controller of the CPLD device would presumably be the SPI slave (although there are CPLDs designs, e.g. Xilinx, that can be a SPI master).

Notes:
Sometimes the SPI controller is so tightly coupled to its device that it's regarded as a "SPI device", such as SPI serial Flash chips (which would be slaves).

Also,would want to know what it mean by interrupt based and poll based SPI transaction

You're asking about how the completion of the transfer is indicated to the SPI driver. This is an interaction between the SPI controller and its processor.
In a multiprocessing OS (e.g. Linux), a driver can suspend the thread after it has initiated an I/O (read or write) operation. The SPI completion-interrupt will trigger execution of the SPI ISR, which will then wakeup the suspended thread and allow the driver to complete the I/O operation.
If an interrupt is not generated on completion, then a polling method is the alternative. At some time interval, the SPI status register would be read and checked for I/O completion. If not complete then the driver would have to continue to wait. If the status indicated that the transfer is complete, then the driver would finish up the operation.

Some SPI slaves may request or require the SPI master to perform a read.
Usually an ad hoc mechanism is employed specific to the SPI slave device.
The device may have an output signal (typically called SPI_IRQ) that could be used to trigger a GPIO interrupt on the host. I'm not aware of any polling schemes to replace this interrupt mechanism.

and why poll based transaction is advisable at boot time?

Most (or all?) boot programs do not have multiprocessing capability. They are usually constrained in size, and therefore usually single threaded.
When a blocking I/O operation is initiated, a multiprocessing (or multithreading) OS can schedule another process or thread to execute, and allow an interrupt to indicate completion of the I/O operation.
But a boot program probably has nothing else to do while waiting for an interrupt.
So dispense with the setup of an interrupt, and just check the status in a wait loop.

BTW "multiprocessing" means more than one process. It has nothing to do with multiprocessors or multicore CPUs.