STM32MP1 SPI DMA Chip Select Delays

[georgenyarangi-eaton]

I am currently using Zephyr v3.0.0-rc3, and I have done work to add SPI DMA support for the STM32MP157 based on the work done in this PR #33913. I cross referenced those changes with the mainline and FRASTM/zephyr@dma_mp1, and I believe that they are correct. Also, SPI DMA has been verified to work with various SPI devices correctly.

The Issue
Prior to switching over to using SPI with DMA, I was using Async SPI with interrupts (i.e., CONFIG_SPI_ASYNC=y & CONFIG_SPI_STM32_INTERRUPT=y). I am talking to a SPI device (ATSENSE301, and I read 14 bytes (1 byte read command & 14 bytes response) from it every time I get an interrupt on the M4 from the ATSENSE301 that there's data to be read over SPI.

Without DMA, the time from enabling/disabling the chip select (AFE_NSS) to the first/last clock edge was ~5us. See annotated logic capture below:

With DMA, there's a significant reduction in the amount of time it takes to clock data in/out which is great; however, the time from enabling/disabling the chip select (AFE_NSS) to the first/last clock edge has increased significantly (CS enable to first clock edge = ~49us, last clock edge to CS disable =~15us). See annotated logic capture below:

Based on the debugging that I have done (no profiling yet), these increased delays seem to be associated with calling into the DMA driver. I have traced the issue down to the spi_dma_move_buffers() call in transceive_dma() in the spi_ll_stm32.c ST SPI driver. Any thoughts or guidance on what can be optimized to minimize these delays would be extremely appreciated.

CC: @erwango @arnopo @FRASTM @shlomow

[arnopo]

Do you have the Linux that runs in parallel on the Cortex-A?
If the answer idyes:
As a first step you have to ensure that the dma is not use by the Linux.
https://wiki.st.com/stm32mpu/wiki/How_to_configure_system_resources
You can also take a look to dma2, dma_mux1 and m4_dma2 node in https://github.com/STMicroelectronics/linux/blob/v5.15-stm32mp/arch/arm/boot/dts/stm32mp157f-dk2-m4-examples.dts, this is the way we assign the dma2 to the Cortex-M4 while the dma1 is used on Linux.

if no you can try to adapt one of the stm32cube SPI example in engineering mode to check if you have same issue.
https://github.com/STMicroelectronics/STM32CubeMP1/tree/master/Projects/STM32MP157C-DK2/Examples/SPI

[bhavikbhansali-eaton]

Hello @arnopo Thanks for reply, I see the details and I am sure that in our case it is configure with M4 only. Also I see that same issue with other controller like STM32U5 and STM32F4 series where issue remain same. It looks like the issue with zephyr drivers. Waiting for suggestion from others.

[erwango]

@FRASTM, can you have a look ?

[bhavikbhansali-eaton]

What I see and understand is that every time when it do communication it try to reconfigure the DMA channel. Is it something the driver structure or driver flow?

[FRASTM]

looking at stm32u5 or stm32F4 ...

[bhavikbhansali-eaton]

Looking for a solution, for STM32MP157C board. Just to cross verify and understand it more did the experiment to see the output in both the board which are STM32U5 and STM32F4. And it is observed that regardless to controller output remains same so it is about the drivers.

[FRASTM]

Does it make any diff when GPIO is defined by
cs-gpios = <&gpiob 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
instead of pinctrl-0 = <&spi1_nss_pe12 ...

[bhavikbhansali-eaton]

Using the cs-gpios only. And in that only above delay observed.

[FRASTM]

When the SPI transfer is using DMA, in the transceive_dma(), the spi_stm32_cs_control(dev, true) is setteing the CS pin a long time before the LL_SPI_EnableDMAReq_ which actually starts the transfer.
Could you please Try with the spi_stm32_cs_control() _just before enabling the DMA req :

diff --git a/drivers/spi/spi_ll_stm32.c b/drivers/spi/spi_ll_stm32.c
index c4f2b36c79..4b79091581 100644
--- a/drivers/spi/spi_ll_stm32.c
+++ b/drivers/spi/spi_ll_stm32.c
@@ -674,7 +674,6 @@ end:
 }
 
 #ifdef CONFIG_SPI_STM32_DMA
-
 static int wait_dma_rx_tx_done(const struct device *dev)
 {
 	struct spi_stm32_data *data = dev->data;
@@ -744,9 +743,6 @@ static int transceive_dma(const struct device *dev,
 	LL_SPI_Enable(spi);
 #endif /* st_stm32h7_spi */
 
-	/* This is turned off in spi_stm32_complete(). */
-	spi_stm32_cs_control(dev, true);
-
 	while (data->ctx.rx_len > 0 || data->ctx.tx_len > 0) {
 		size_t dma_len;
 
@@ -765,6 +761,9 @@ static int transceive_dma(const struct device *dev,
 			break;
 		}
 
+ 		/* This is turned off in spi_stm32_complete(). */
+ 		spi_stm32_cs_control(dev, true);
+
 #if !DT_HAS_COMPAT_STATUS_OKAY(st_stm32h7_spi)
 
 		/* toggle the DMA request to restart the transfer */

This is just a WA since, the cs gpio should not be set (true) each loop but only at the beginning of the DMA transfer.
Controlling with the data->status_flags will avoid that.

[bhavikbhansali-eaton]

I took a reference of this did some more modification and able to reduce time from ~15us to ~900ns (in production mode).

[FRASTM]

[bhavikbhansali-eaton]

I am checking on STM32MP157 but no success. Any Idea or Guidance?

[FRASTM]

With the stm32MP157, did you enable the dmamux for the spi transfer ?
on top of the FRASTM/zephyr@spi_dma_CS
For example :

&spi4 {
	dmas = <&dmamux 11 84 0x20440
		&dmamux 1 83 0x20480>;
	dma-names = "tx", "rx";
};

However, the stm32mp157c_dk2.dts is defining 2 spi nodes spi4 and spi5 with nss pin (not cs-gpios).
I guess in your config you should have
cs-gpios = <&gpioX N (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;

[bhavikbhansali-eaton]

Hello @FRASTM Thanks for support will able to solve issue in our case. It looks like driver need to be modified a bit. Once I will get time out of my current work will gonna fix it.

Thanks for the help. As of now have to check weather it is generic or not and working on it.

[erwango]

@bhavikbhansali-eaton Does this mean that the fix provided here is solving your issue ?

[erwango]

In any case, please keep up informed and if possible share the working fix

[bhavikbhansali-eaton]

Trying to setup and check the solution/WA in our case.