From: Jonathan Cameron <Jonathan.Cameron@Huawei.com> To: David Lechner <dlechner@baylibre.com> Cc: "Mark Brown" <broonie@kernel.org>, "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: Re: [PATCH 2/5] spi: move splitting transfers to spi_optimize_message() Date: Tue, 13 Feb 2024 17:35:45 +0000 [thread overview] Message-ID: <20240213173545.00006564@Huawei.com> (raw) In-Reply-To: <20240212-mainline-spi-precook-message-v1-2-a2373cd72d36@baylibre.com> On Mon, 12 Feb 2024 17:26:42 -0600 David Lechner <dlechner@baylibre.com> wrote: > Splitting transfers is an expensive operation so we can potentially > optimize it by doing it only once per optimization of the message > instead of repeating each time the message is transferred. > > The transfer splitting functions are currently the only user of > spi_res_alloc() so spi_res_release() can be safely moved at this time > from spi_finalize_current_message() to spi_unoptimize_message(). > > The doc comments of the public functions for splitting transfers are > also updated so that callers will know when it is safe to call them > to ensure proper resource management. > > Signed-off-by: David Lechner <dlechner@baylibre.com> > --- Trivial thing (which applies equally to the original code). Otherwise LGTM. FWIW Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > +/** > + * spi_split_transfers - generic handling of transfer splitting > + * @msg: the message to split > + * > + * Under certain conditions, a SPI controller may not support arbitrary > + * transfer sizes or other features required by a peripheral. This function > + * will split the transfers in the message into smaller transfers that are > + * supported by the controller. > + * > + * Controllers with special requirements not covered here can also split > + * transfers in the optimize_message() callback. > + * > + * Context: can sleep > + * Return: zero on success, else a negative error code > + */ > +static int spi_split_transfers(struct spi_message *msg) > +{ > + struct spi_controller *ctlr = msg->spi->controller; > + struct spi_transfer *xfer; > + int ret; > + > + /* > + * If an SPI controller does not support toggling the CS line on each > + * transfer (indicated by the SPI_CS_WORD flag) or we are using a GPIO > + * for the CS line, we can emulate the CS-per-word hardware function by > + * splitting transfers into one-word transfers and ensuring that > + * cs_change is set for each transfer. > + */ > + if ((msg->spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) || > + spi_is_csgpiod(msg->spi))) { if ((msg->spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) || spi_is_csgpiod(msg->spi))) { Seems easier to read to me. I appreciate you are just moving it though so don't mind that much if you leave it in the original form. > + ret = spi_split_transfers_maxwords(ctlr, msg, 1); > + if (ret) > + return ret; > + > + list_for_each_entry(xfer, &msg->transfers, transfer_list) { > + /* Don't change cs_change on the last entry in the list */ > + if (list_is_last(&xfer->transfer_list, &msg->transfers)) > + break; > + > + xfer->cs_change = 1; > + } > + } else { > + ret = spi_split_transfers_maxsize(ctlr, msg, > + spi_max_transfer_size(msg->spi)); > + if (ret) > + return ret; > + } > + > + return 0; > +}
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com> To: David Lechner <dlechner@baylibre.com> Cc: "Mark Brown" <broonie@kernel.org>, "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: Re: [PATCH 2/5] spi: move splitting transfers to spi_optimize_message() Date: Tue, 13 Feb 2024 17:35:45 +0000 [thread overview] Message-ID: <20240213173545.00006564@Huawei.com> (raw) In-Reply-To: <20240212-mainline-spi-precook-message-v1-2-a2373cd72d36@baylibre.com> On Mon, 12 Feb 2024 17:26:42 -0600 David Lechner <dlechner@baylibre.com> wrote: > Splitting transfers is an expensive operation so we can potentially > optimize it by doing it only once per optimization of the message > instead of repeating each time the message is transferred. > > The transfer splitting functions are currently the only user of > spi_res_alloc() so spi_res_release() can be safely moved at this time > from spi_finalize_current_message() to spi_unoptimize_message(). > > The doc comments of the public functions for splitting transfers are > also updated so that callers will know when it is safe to call them > to ensure proper resource management. > > Signed-off-by: David Lechner <dlechner@baylibre.com> > --- Trivial thing (which applies equally to the original code). Otherwise LGTM. FWIW Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > +/** > + * spi_split_transfers - generic handling of transfer splitting > + * @msg: the message to split > + * > + * Under certain conditions, a SPI controller may not support arbitrary > + * transfer sizes or other features required by a peripheral. This function > + * will split the transfers in the message into smaller transfers that are > + * supported by the controller. > + * > + * Controllers with special requirements not covered here can also split > + * transfers in the optimize_message() callback. > + * > + * Context: can sleep > + * Return: zero on success, else a negative error code > + */ > +static int spi_split_transfers(struct spi_message *msg) > +{ > + struct spi_controller *ctlr = msg->spi->controller; > + struct spi_transfer *xfer; > + int ret; > + > + /* > + * If an SPI controller does not support toggling the CS line on each > + * transfer (indicated by the SPI_CS_WORD flag) or we are using a GPIO > + * for the CS line, we can emulate the CS-per-word hardware function by > + * splitting transfers into one-word transfers and ensuring that > + * cs_change is set for each transfer. > + */ > + if ((msg->spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) || > + spi_is_csgpiod(msg->spi))) { if ((msg->spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) || spi_is_csgpiod(msg->spi))) { Seems easier to read to me. I appreciate you are just moving it though so don't mind that much if you leave it in the original form. > + ret = spi_split_transfers_maxwords(ctlr, msg, 1); > + if (ret) > + return ret; > + > + list_for_each_entry(xfer, &msg->transfers, transfer_list) { > + /* Don't change cs_change on the last entry in the list */ > + if (list_is_last(&xfer->transfer_list, &msg->transfers)) > + break; > + > + xfer->cs_change = 1; > + } > + } else { > + ret = spi_split_transfers_maxsize(ctlr, msg, > + spi_max_transfer_size(msg->spi)); > + if (ret) > + return ret; > + } > + > + return 0; > +} _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-13 17:35 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-12 23:26 [PATCH 0/5] spi: add support for pre-cooking messages David Lechner 2024-02-12 23:26 ` 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 [this message] 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=20240213173545.00006564@Huawei.com \ --to=jonathan.cameron@huawei.com \ --cc=alain.volmat@foss.st.com \ --cc=alexandre.torgue@foss.st.com \ --cc=broonie@kernel.org \ --cc=david@protonic.nl \ --cc=dlechner@baylibre.com \ --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.