On 03/29/2015 08:03 AM, Martin Sperl wrote:
> reduce interrupts/message
>
> To reduce the number of interrupts/message we fill the FIFO before
> enabling interrupts - for short messages this reduces the interrupt count
> from 2 to 1 interrupt.
>
> There have been rare cases where short (<200ns) chip-select switches with
> native CS have been observed during such operation, this is why this
> optimization is only enabled for GPIO-CS.
> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
> + /* fill in fifo if we have gpio-cs
> + * note that there have been rare events where the native-CS
> + * flapped for <1us which may change the behaviour
> + * with gpio-cs this does not happen, so it is implemented
> + * only for this case
> + */
> + if (gpio_is_valid(spi->cs_gpio)) {
> + /* enable HW block, but without interrupts enabled
> + * this would triggern an immediate interrupt
> + */
> + bcm2835_wr(bs, BCM2835_SPI_CS,
> + cs | BCM2835_SPI_CS_TA);
> + /* fill in tx fifo as much as possible */
> + bcm2835_wr_fifo(bs);
> + }
I can understand perfectly why the code fills the FIFO before enabling
interrupts; it avoids having to immediately service an interrupt simply
to fill the FIFO.
However, I'm not sure why this is in any way related to whether the
chip-select GPIO is valid. Surely we always want to do this? How does
the mechanism used to control chip selects influence whether we want to
pre-fill the FIFO?
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
