mbox series

[v2,00/10] Speed up SPI simplex transfers on Raspberry Pi

Message ID cover.1568187525.git.lukas@wunner.de (mailing list archive)
Headers show
Series Speed up SPI simplex transfers on Raspberry Pi | expand

Message

Lukas Wunner Sept. 11, 2019, 10:15 a.m. UTC
Extend the BCM2835 SPI driver to handle simplex transfers internally,
thereby reducing their latency and CPU usage and obviating the need to
have the SPI core convert to full-duplex via SPI_CONTROLLER_MUST_TX/RX.


Changes since v2:

* Patch [03/10]: Round up struct spi_controller to cacheline size
  instead of putting it behind the driver-private data. (Mark Brown)

* Move patch "spi: bcm2835: Work around DONE bit erratum" to the front
  of the series to ease backporting to stable. (Mark Brown)
  (I don't think it's necessary to backport it, hence it's not marked
  for stable, but it might be autoselected by Sasha Levin's AI.)

* Add all collected Acked-by and Tested-by tags, rebase on for-5.4.


Link to v1:

https://lore.kernel.org/dmaengine/20190910112141.GM2036@sirena.org.uk/T/#t


Lukas Wunner (10):
  dmaengine: bcm2835: Allow reusable descriptors
  dmaengine: bcm2835: Allow cyclic transactions without interrupt
  spi: Guarantee cacheline alignment of driver-private data
  spi: bcm2835: Work around DONE bit erratum
  spi: bcm2835: Drop dma_pending flag
  spi: bcm2835: Cache CS register value for ->prepare_message()
  spi: bcm2835: Speed up TX-only DMA transfers by clearing RX FIFO
  dmaengine: bcm2835: Document struct bcm2835_dmadev
  dmaengine: bcm2835: Avoid accessing memory when copying zeroes
  spi: bcm2835: Speed up RX-only DMA transfers by zero-filling TX FIFO

 drivers/dma/bcm2835-dma.c |  38 +++-
 drivers/spi/spi-bcm2835.c | 407 +++++++++++++++++++++++++++++++-------
 drivers/spi/spi.c         |  11 +-
 3 files changed, 384 insertions(+), 72 deletions(-)

Comments

Mark Brown Sept. 11, 2019, 10:47 a.m. UTC | #1
On Wed, Sep 11, 2019 at 12:15:30PM +0200, Lukas Wunner wrote:
> Extend the BCM2835 SPI driver to handle simplex transfers internally,
> thereby reducing their latency and CPU usage and obviating the need to
> have the SPI core convert to full-duplex via SPI_CONTROLLER_MUST_TX/RX.

Whatever you're doing to send these is still not sending the
patches in order:

    779 N T 09/11 Lukas Wunner    (1.6K) [PATCH v2 00/10] Speed up SPI simplex t
    780 N T 09/11 Lukas Wunner    (2.1K) ├─>[PATCH v2 02/10] dmaengine: bcm2835:
    781 N T 09/11 Lukas Wunner    (1.3K) ├─>[PATCH v2 01/10] dmaengine: bcm2835:
    782 N T 09/11 Lukas Wunner    (2.6K) ├─>[PATCH v2 03/10] spi: Guarantee cac
Lukas Wunner Sept. 11, 2019, 11:43 a.m. UTC | #2
On Wed, Sep 11, 2019 at 11:47:21AM +0100, Mark Brown wrote:
> On Wed, Sep 11, 2019 at 12:15:30PM +0200, Lukas Wunner wrote:
> > Extend the BCM2835 SPI driver to handle simplex transfers internally,
> > thereby reducing their latency and CPU usage and obviating the need to
> > have the SPI core convert to full-duplex via SPI_CONTROLLER_MUST_TX/RX.
> 
> Whatever you're doing to send these is still not sending the
> patches in order:

I use "git format-patch --thread=shallow", then use a Perl script
to change the Date: header and send out the raw messages with msmtp.

I suspect the incorrect order may be because all messages use the
same Date: header and you're using "sort_aux=date-sent" in Mutt.

I'll change my workflow to use incremental Date: headers.
Sorry for the inconvenience.

You can work around the incorrect order by limiting to messages
from me (type "l", enter "~f lukas@wunner.de"), then ordering
by subject (type "o", then "s").

Thanks,

Lukas
Mark Brown Sept. 11, 2019, 11:59 a.m. UTC | #3
On Wed, Sep 11, 2019 at 01:43:52PM +0200, Lukas Wunner wrote:

> I use "git format-patch --thread=shallow", then use a Perl script
> to change the Date: header and send out the raw messages with msmtp.

Sounds like your perl script could just be git send-email?

> I suspect the incorrect order may be because all messages use the
> same Date: header and you're using "sort_aux=date-sent" in Mutt.

or that the messages are getting reordered in transit by the
intervening MTAs and it's falling back on delivery order lacking
any other information.