| Message ID | 20220525142928.2335378-1-david@protonic.nl (mailing list archive) |
|---|---|
| Headers | show |
| Series | Optimize spi_sync path | expand |
On Wed, May 25, 2022 at 04:29:25PM +0200, David Jander wrote: > Unfortunately though, this optimization requires a small and hopefully > innocuous API change. This change is contained in the first patch, and > it replaces the function spi_finalize_current_message() with > spi_finalize_message(), which takes the message instead of its > controller as argument. Without this change, it is not possible to avoid > touching the controller message queue, which is what this is all about. You're right it needs at least a bit of thought here - unfortunately I'm out of the office this week so I'm not sure I'll have bandwidth to review this properly until next week.
These patches optimize the spi_sync call for the common case that the worker thread is idle and the queue is empty. It also opens the possibility to potentially further optimize the async path also, since it doesn't need to take into account the direct sync path anymore. As an example for the performance gain, on an i.MX8MM SoC with a SPI CAN controller attached (MCP2518FD), the time the interrupt line stays active (which corresponds roughly with the time it takes to send 3 relatively short consecutive spi_sync messages) is reduced from 98us to only 72us by this patch. Unfortunately though, this optimization requires a small and hopefully innocuous API change. This change is contained in the first patch, and it replaces the function spi_finalize_current_message() with spi_finalize_message(), which takes the message instead of its controller as argument. Without this change, it is not possible to avoid touching the controller message queue, which is what this is all about. A note about message ordering: This patch series should not change the behavior of message ordering when coming from the same context. This means that if a client driver issues one or more spi_async() messages immediately followed by a spi_sync() message in the same context, it can still rely on these messages being sent out in the order they were fired. David Jander (3): drivers: spi: API: spi_finalize_current_message -> spi_finalize_message drivers: spi: spi.c: Move ctlr->cur_msg_prepared to struct spi_message drivers: spi: spi.c: Don't use the message queue if possible in spi_sync Documentation/spi/spi-summary.rst | 4 +- .../media/pci/netup_unidvb/netup_unidvb_spi.c | 2 +- drivers/media/usb/msi2500/msi2500.c | 2 +- drivers/spi/spi-amd.c | 2 +- drivers/spi/spi-ar934x.c | 2 +- drivers/spi/spi-axi-spi-engine.c | 2 +- drivers/spi/spi-bcm63xx-hsspi.c | 2 +- drivers/spi/spi-bcm63xx.c | 2 +- drivers/spi/spi-cavium.c | 2 +- drivers/spi/spi-falcon.c | 2 +- drivers/spi/spi-fsi.c | 2 +- drivers/spi/spi-fsl-dspi.c | 2 +- drivers/spi/spi-fsl-espi.c | 2 +- drivers/spi/spi-fsl-spi.c | 2 +- drivers/spi/spi-mpc512x-psc.c | 2 +- drivers/spi/spi-mt7621.c | 2 +- drivers/spi/spi-mtk-nor.c | 2 +- drivers/spi/spi-mux.c | 2 +- drivers/spi/spi-mxs.c | 2 +- drivers/spi/spi-omap-100k.c | 2 +- drivers/spi/spi-pic32-sqi.c | 2 +- drivers/spi/spi-pl022.c | 4 +- drivers/spi/spi-sc18is602.c | 2 +- drivers/spi/spi-sh-hspi.c | 2 +- drivers/spi/spi-tegra114.c | 2 +- drivers/spi/spi-tegra20-sflash.c | 2 +- drivers/spi/spi-tegra210-quad.c | 2 +- drivers/spi/spi-ti-qspi.c | 2 +- drivers/spi/spi-xcomm.c | 2 +- drivers/spi/spi.c | 269 ++++++++++-------- drivers/staging/greybus/spilib.c | 2 +- include/linux/spi/spi.h | 21 +- 32 files changed, 206 insertions(+), 148 deletions(-)