| Message ID | 20241023-dlech-mainline-spi-engine-offload-2-v4-0-f8125b99f5a1@baylibre.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | spi: axi-spi-engine: add offload support | expand |
Hi David, On Wed, 2024-10-23 at 15:59 -0500, David Lechner wrote: > In this revision, I ended up changing quite a bit more that I was > expecting. > > In the DT bindings, I ended up dropping the #spi-offload-cells and > spi-offload properties. A couple of reasons for this: > > 1. Several people commented that it is odd to have a separate provider/ > consumer binding for something that already has a parent/child > relationship (both on this series and in another unrelated series > with io-backends). For now, the only SPI offload provider is the AXI > SPI Engine, which is a SPI controller. > 2. In a discussion unrelated to this series, but related to the idea > of SPI offloads [1], it became apparent that the proposed use for > the cells to select triggers and tx/rx streams doesn't actually > work for that case. > 3. In offline review, it was suggested that assigning specific offloads > to specific peripherals may be too restrictive, e.g. if there are > controllers that have pools of identical offloads. This idea of > pools of generic offloads has also come up in previous discussions > on the mailing list. > > [1]: > https://lore.kernel.org/linux-iio/e5310b63-9dc4-43af-9fbe-0cc3b604ab8b@baylibre.com/ > > So the idea is that if we do end up needing to use DT to assign certain > resources (triggers, DMA channels, etc.) to specific peripherals, we > would make a mapping attribute in the controller node rather than using > phandle cells. But we don't need this yet, so it isn't present in The > current patches. > > And if we ever end up with a SPI offload provider that is not a SPI > controller, we can bring back the #spi-offload-cells and > spi-offload properties. Well I do like we kind of gave a step back and are more focused in supporting what we have and know at the moment. And I think (for what I saw so far) things are being implemented in fairly flexible manner. So yeah, as far as I'm concerned, I liked what I saw so far. Hopefully everyone can agree on this so we drop the RFC :) I'll try to look at the remaining patches tomorrow... - Nuno Sá
In this revision, I ended up changing quite a bit more that I was expecting. In the DT bindings, I ended up dropping the #spi-offload-cells and spi-offload properties. A couple of reasons for this: 1. Several people commented that it is odd to have a separate provider/ consumer binding for something that already has a parent/child relationship (both on this series and in another unrelated series with io-backends). For now, the only SPI offload provider is the AXI SPI Engine, which is a SPI controller. 2. In a discussion unrelated to this series, but related to the idea of SPI offloads [1], it became apparent that the proposed use for the cells to select triggers and tx/rx streams doesn't actually work for that case. 3. In offline review, it was suggested that assigning specific offloads to specific peripherals may be too restrictive, e.g. if there are controllers that have pools of identical offloads. This idea of pools of generic offloads has also come up in previous discussions on the mailing list. [1]: https://lore.kernel.org/linux-iio/e5310b63-9dc4-43af-9fbe-0cc3b604ab8b@baylibre.com/ So the idea is that if we do end up needing to use DT to assign certain resources (triggers, DMA channels, etc.) to specific peripherals, we would make a mapping attribute in the controller node rather than using phandle cells. But we don't need this yet, so it isn't present in The current patches. And if we ever end up with a SPI offload provider that is not a SPI controller, we can bring back the #spi-offload-cells and spi-offload properties. Regarding the SPI core changes, there are more details on each individual patch, but a lot has changed there due to adding a second ADC consumer that is wired up differently. The AD7944 is as pictured below, but the AD4695 that has been added has the ADC chip itself as the SPI offload trigger source, which I found to not be compatible with many of the assumptions we made in previous revisions. So there isn't much that is still the same as in previous revisions. --- Changes in v4: - Dropped #spi-offload-cells and spi-offload properties from DT bindings. - Made an attempt at a more generic trigger interface instead of using clk framework. This also includes a new driver for a generic PWM trigger. - Addressed IIO review comments. - Added new patches for iio/adc/ad4695 as 2nd user of SPI offload. - Link to v3: https://lore.kernel.org/r/20240722-dlech-mainline-spi-engine-offload-2-v3-0-7420e45df69b@baylibre.com Changes in v3: - Reworked DT bindings to have things physically connected to the SPI controller be properties of the SPI controller and use more conventional provider/consumer properties. - Added more SPI APIs for peripheral drivers to use to get auxillary offload resources, like triggers. - Link to v2: https://lore.kernel.org/r/20240510-dlech-mainline-spi-engine-offload-2-v2-0-8707a870c435@baylibre.com Individual patches have more details on these changes and earlier revisions too. --- As a recap, here is the background and end goal of this series: The AXI SPI Engine is a SPI controller that has the ability to record a series of SPI transactions and then play them back using a hardware trigger. This allows operations to be performed, repeating many times, without any CPU intervention. This is needed for achieving high data rates (millions of samples per second) from ADCs and DACs that are connected via a SPI bus. The offload hardware interface consists of a trigger input and a data output for the RX data. These are connected to other hardware external to the SPI controller. To record one or more transactions, commands and TX data are written to memories in the controller (RX buffer is not used since RX data gets streamed to an external sink). This sequence of transactions can then be played back when the trigger input is asserted. This series includes core SPI support along with the first SPI controller (AXI SPI Engine) and SPI peripheral (AD7944 ADC) that use them. This enables capturing analog data at 2 million samples per second. The hardware setup looks like this: +-------------------------------+ +------------------+ | | | | | SOC/FPGA | | AD7944 ADC | | +---------------------+ | | | | | AXI SPI Engine | | | | | | SPI Bus ============ SPI Bus | | | | | | | | | +---------------+ | | | | | | | Offload 0 | | | +------------------+ | | | RX DATA OUT > > > > | | | | TRIGGER IN < < < v | | | +---------------+ | ^ v | | +---------------------+ ^ v | | | AXI PWM | ^ v | | | CH0 > ^ v | | +---------------------+ v | | | AXI DMA | v | | | CH0 < < < | | +---------------------+ | | | +-------------------------------+ --- David Lechner (15): pwm: core: export pwm_get_state_hw() spi: add basic support for SPI offloading spi: offload: add support for hardware triggers spi: dt-bindings: add trigger-source.yaml spi: dt-bindings: add PWM SPI offload trigger spi: offload-trigger: add PWM trigger driver spi: add offload TX/RX streaming APIs spi: dt-bindings: axi-spi-engine: add SPI offload properties spi: axi-spi-engine: implement offload support iio: buffer-dmaengine: document iio_dmaengine_buffer_setup_ext iio: buffer-dmaengine: add devm_iio_dmaengine_buffer_setup_ext2() iio: adc: ad7944: don't use storagebits for sizing iio: adc: ad7944: add support for SPI offload dt-bindings: iio: adc: adi,ad4695: add SPI offload properties iio: adc: ad4695: Add support for SPI offload .../devicetree/bindings/iio/adc/adi,ad4695.yaml | 13 +- .../bindings/spi/adi,axi-spi-engine.yaml | 22 + .../devicetree/bindings/spi/trigger-pwm.yaml | 39 ++ .../devicetree/bindings/spi/trigger-source.yaml | 28 ++ drivers/iio/adc/Kconfig | 2 + drivers/iio/adc/ad4695.c | 470 +++++++++++++++++++-- drivers/iio/adc/ad7944.c | 249 ++++++++++- drivers/iio/buffer/industrialio-buffer-dmaengine.c | 104 ++++- drivers/pwm/core.c | 55 ++- drivers/spi/Kconfig | 16 + drivers/spi/Makefile | 4 + drivers/spi/spi-axi-spi-engine.c | 273 +++++++++++- drivers/spi/spi-offload-trigger-pwm.c | 169 ++++++++ drivers/spi/spi-offload.c | 446 +++++++++++++++++++ drivers/spi/spi.c | 10 + include/linux/iio/buffer-dmaengine.h | 5 + include/linux/pwm.h | 1 + include/linux/spi/spi-offload.h | 166 ++++++++ include/linux/spi/spi.h | 19 + 19 files changed, 1995 insertions(+), 96 deletions(-) --- base-commit: 6c4b0dd7d0df3a803766d4954dc064dc57aeda17 change-id: 20240510-dlech-mainline-spi-engine-offload-2-afce3790b5ab Best regards,