All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Lechner <dlechner@baylibre.com>
To: Mark Brown <broonie@kernel.org>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Martin Sperl" <kernel@martin.sperl.org>,
	"David Jander" <david@protonic.nl>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Michael Hennerich" <michael.hennerich@analog.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Alain Volmat" <alain.volmat@foss.st.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, linux-iio@vger.kernel.org
Subject: [PATCH 0/5] spi: add support for pre-cooking messages
Date: Mon, 12 Feb 2024 17:26:40 -0600	[thread overview]
Message-ID: <20240212-mainline-spi-precook-message-v1-0-a2373cd72d36@baylibre.com> (raw)

This is a follow-up to [1] where it was suggested to break down the
proposed SPI offload support into smaller series.

This takes on the first suggested task of introducing an API to
"pre-cook" SPI messages. This idea was first discussed extensively in
2013 [2][3] and revisited more briefly 2022 [4].

The goal here is to be able to improve performance (higher throughput,
and reduced CPU usage) by allowing peripheral drivers that use the
same struct spi_message repeatedly to "pre-cook" the message once to
avoid repeating the same validation, and possibly other operations each
time the message is sent.

This series includes __spi_validate() and the automatic splitting of
xfers in the optimizations. Another frequently suggested optimization
is doing DMA mapping only once. This is not included in this series, but
can be added later (preferably by someone with a real use case for it).

To show how this all works and get some real-world measurements, this
series includes the core changes, optimization of a SPI controller
driver, and optimization of an ADC driver. This test case was only able
to take advantage of the single validation optimization, since it didn't
require splitting transfers. With these changes, CPU usage of the
threaded interrupt handler, which calls spi_sync(), was reduced from
83% to 73% while at the same time the sample rate (frequency of SPI
xfers) was increased from 20kHz to 25kHz.

Finally, there has been quite a bit of discussion on the naming of the
API already. The most natural suggestion of spi_message_[un]prepare()
conflicts with the existing prepare_message controller callback which
does something a bit different. I've so far stuck with [un]optimize()
from [3], but am not partial to it. Maybe [un]cook() would makes more
sense to people? Or maybe we could rename the existing prepare_message
callback to free up the name?

[1]: https://lore.kernel.org/linux-spi/20240109-axi-spi-engine-series-3-v1-1-e42c6a986580@baylibre.com/T/
[2]: https://lore.kernel.org/linux-spi/E81F4810-48DD-41EE-B110-D0D848B8A510@martin.sperl.org/T/
[3]: https://lore.kernel.org/linux-spi/39DEC004-10A1-47EF-9D77-276188D2580C@martin.sperl.org/T/
[4]: https://lore.kernel.org/linux-spi/20220525163946.48ea40c9@erd992/T/

---
David Lechner (5):
      spi: add spi_optimize_message() APIs
      spi: move splitting transfers to spi_optimize_message()
      spi: stm32: move splitting transfers to optimize_message
      spi: axi-spi-engine: move message compile to optimize_message
      iio: adc: ad7380: use spi_optimize_message()

 drivers/iio/adc/ad7380.c         |  52 ++++++--
 drivers/spi/spi-axi-spi-engine.c |  40 +++----
 drivers/spi/spi-stm32.c          |  28 +++--
 drivers/spi/spi.c                | 253 ++++++++++++++++++++++++++++++++-------
 include/linux/spi/spi.h          |  19 +++
 5 files changed, 305 insertions(+), 87 deletions(-)
---
base-commit: 5111fd347aee731964993fc021e428f8cf46a076
prerequisite-patch-id: 844c06b6caf25a2724e130dfa7999dc90dd26fde
change-id: 20240208-mainline-spi-precook-message-189b2f08ba7f

WARNING: multiple messages have this Message-ID (diff)
From: David Lechner <dlechner@baylibre.com>
To: Mark Brown <broonie@kernel.org>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Martin Sperl" <kernel@martin.sperl.org>,
	"David Jander" <david@protonic.nl>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Michael Hennerich" <michael.hennerich@analog.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Alain Volmat" <alain.volmat@foss.st.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, linux-iio@vger.kernel.org
Subject: [PATCH 0/5] spi: add support for pre-cooking messages
Date: Mon, 12 Feb 2024 17:26:40 -0600	[thread overview]
Message-ID: <20240212-mainline-spi-precook-message-v1-0-a2373cd72d36@baylibre.com> (raw)

This is a follow-up to [1] where it was suggested to break down the
proposed SPI offload support into smaller series.

This takes on the first suggested task of introducing an API to
"pre-cook" SPI messages. This idea was first discussed extensively in
2013 [2][3] and revisited more briefly 2022 [4].

The goal here is to be able to improve performance (higher throughput,
and reduced CPU usage) by allowing peripheral drivers that use the
same struct spi_message repeatedly to "pre-cook" the message once to
avoid repeating the same validation, and possibly other operations each
time the message is sent.

This series includes __spi_validate() and the automatic splitting of
xfers in the optimizations. Another frequently suggested optimization
is doing DMA mapping only once. This is not included in this series, but
can be added later (preferably by someone with a real use case for it).

To show how this all works and get some real-world measurements, this
series includes the core changes, optimization of a SPI controller
driver, and optimization of an ADC driver. This test case was only able
to take advantage of the single validation optimization, since it didn't
require splitting transfers. With these changes, CPU usage of the
threaded interrupt handler, which calls spi_sync(), was reduced from
83% to 73% while at the same time the sample rate (frequency of SPI
xfers) was increased from 20kHz to 25kHz.

Finally, there has been quite a bit of discussion on the naming of the
API already. The most natural suggestion of spi_message_[un]prepare()
conflicts with the existing prepare_message controller callback which
does something a bit different. I've so far stuck with [un]optimize()
from [3], but am not partial to it. Maybe [un]cook() would makes more
sense to people? Or maybe we could rename the existing prepare_message
callback to free up the name?

[1]: https://lore.kernel.org/linux-spi/20240109-axi-spi-engine-series-3-v1-1-e42c6a986580@baylibre.com/T/
[2]: https://lore.kernel.org/linux-spi/E81F4810-48DD-41EE-B110-D0D848B8A510@martin.sperl.org/T/
[3]: https://lore.kernel.org/linux-spi/39DEC004-10A1-47EF-9D77-276188D2580C@martin.sperl.org/T/
[4]: https://lore.kernel.org/linux-spi/20220525163946.48ea40c9@erd992/T/

---
David Lechner (5):
      spi: add spi_optimize_message() APIs
      spi: move splitting transfers to spi_optimize_message()
      spi: stm32: move splitting transfers to optimize_message
      spi: axi-spi-engine: move message compile to optimize_message
      iio: adc: ad7380: use spi_optimize_message()

 drivers/iio/adc/ad7380.c         |  52 ++++++--
 drivers/spi/spi-axi-spi-engine.c |  40 +++----
 drivers/spi/spi-stm32.c          |  28 +++--
 drivers/spi/spi.c                | 253 ++++++++++++++++++++++++++++++++-------
 include/linux/spi/spi.h          |  19 +++
 5 files changed, 305 insertions(+), 87 deletions(-)
---
base-commit: 5111fd347aee731964993fc021e428f8cf46a076
prerequisite-patch-id: 844c06b6caf25a2724e130dfa7999dc90dd26fde
change-id: 20240208-mainline-spi-precook-message-189b2f08ba7f

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2024-02-12 23:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 23:26 David Lechner [this message]
2024-02-12 23:26 ` [PATCH 0/5] spi: add support for pre-cooking messages David Lechner
2024-02-12 23:26 ` [PATCH 1/5] spi: add spi_optimize_message() APIs David Lechner
2024-02-12 23:26   ` David Lechner
2024-02-13  9:53   ` Nuno Sá
2024-02-13  9:53     ` Nuno Sá
2024-02-13 15:38     ` David Lechner
2024-02-13 15:38       ` David Lechner
2024-02-13 17:55     ` Mark Brown
2024-02-13 17:55       ` Mark Brown
2024-02-13 17:25   ` Jonathan Cameron
2024-02-13 17:25     ` Jonathan Cameron
2024-02-13 19:20     ` David Lechner
2024-02-13 19:20       ` David Lechner
2024-02-13 18:55   ` Mark Brown
2024-02-13 18:55     ` Mark Brown
2024-02-13 19:26     ` David Lechner
2024-02-13 19:26       ` David Lechner
2024-02-13 19:28       ` Mark Brown
2024-02-13 19:28         ` Mark Brown
2024-02-12 23:26 ` [PATCH 2/5] spi: move splitting transfers to spi_optimize_message() David Lechner
2024-02-12 23:26   ` David Lechner
2024-02-13 17:35   ` Jonathan Cameron
2024-02-13 17:35     ` Jonathan Cameron
2024-02-12 23:26 ` [PATCH 3/5] spi: stm32: move splitting transfers to optimize_message David Lechner
2024-02-12 23:26   ` David Lechner
2024-02-12 23:26 ` [PATCH 4/5] spi: axi-spi-engine: move message compile " David Lechner
2024-02-12 23:26   ` David Lechner
2024-02-12 23:26 ` [PATCH 5/5] iio: adc: ad7380: use spi_optimize_message() David Lechner
2024-02-12 23:26   ` David Lechner
2024-02-13  9:51   ` Nuno Sá
2024-02-13  9:51     ` Nuno Sá
2024-02-13 15:27     ` David Lechner
2024-02-13 15:27       ` David Lechner
2024-02-13 16:08       ` Nuno Sá
2024-02-13 16:08         ` Nuno Sá
2024-02-13 17:31         ` Jonathan Cameron
2024-02-13 17:31           ` Jonathan Cameron
2024-02-13 18:59           ` David Lechner
2024-02-13 18:59             ` David Lechner
2024-02-13 17:28   ` Jonathan Cameron
2024-02-13 17:28     ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240212-mainline-spi-precook-message-v1-0-a2373cd72d36@baylibre.com \
    --to=dlechner@baylibre.com \
    --cc=alain.volmat@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=broonie@kernel.org \
    --cc=david@protonic.nl \
    --cc=jic23@kernel.org \
    --cc=kernel@martin.sperl.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=michael.hennerich@analog.com \
    --cc=nuno.sa@analog.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.