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
next 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: linkBe 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.