drivers: dma: stm32: only control IRQ settings in dma_config

[benedekkupper]

The current implementation doesn't allow (re)starting a DMA transfer either via dma_start or dma_reload after dma_stop has been called, as dma_stop disables the completion IRQ, and dma_start and dma_reload don't enable them.

Since the DMA stream doesn't trigger interrupts when disabled, disabling the stream itself in dma_stop is sufficient, so dma_config shall be responsible for enabling and for disabling the IRQs, depending on the configuration.

With this change in place, many drivers using dma could perform the dma_config in their init method (as most of the configuration is fixed or defined in DT), and only rely on dma_reload / dma_start and dma_stop API at the rest of the runtime.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[etienne-lms]

LGTM

[djiatsaf-st]

Hello,

I ran the tests tests/drivers/spi/spi_loopback and tests/drivers/uart/uart_async_api with the related changes in this PR.

There were some issues encountered during tests on platforms with DMA v1 compatibility (nucleo_f429zi, nucleo_f746zg, nucleo_f207zg, nucleo_h753zi (+ dmamux)) and DMA U5 compatibility (nucleo_wba55cg).

• tests/drivers/uart/uart_async_api: Failed to configure DMA/DMAMUX, and possibly IRQs were not properly disabled.

Logs:

Running TESTSUITE uart_async_write_abort  
===================================================================  
UART instance: serial@40011400  
START - test_write_abort  
E: dma stream 2 is busy.  
E: UART ERR: RX DMA config failed!  
   Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/uart/uart_async_api/src/test_uart_async.c:890: uart_async_chain_write_test_chained_write: (k_sem_take(&rx_rdy, K_MSEC(100)) not equal to 0)
RX_RDY timeout

nucleo_h753zi:

Running TESTSUITE uart_async_chain_read  
===================================================================  
UART instance: serial@40004400  
START - test_chained_read  

Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/uart/uart_async_api/src/test_uart_async.c:386: test_chained_read_callback: err not equal to 0  

FAIL - test_chained_read in 0.441 seconds  
===================================================================  
TESTSUITE uart_async_chain_read failed.  
Running TESTSUITE uart_async_chain_write  
===================================================================  
UART instance: serial@40004400  
START - test_chained_write  
E: dma stream 3 is busy.  
E: cannot configure the dmamux.  
E: UART ERR: RX DMA config failed!  

Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/uart/uart_async_api/src/test_uart_async.c:890: uart_async_chain_write_test_chained_write: (k_sem_take(&rx_rdy, K_MSEC(100)) not equal to 0)  
RX_RDY timeout  

FAIL - test_chained_write in 0.129 seconds  

Platforms affected: nucleo_f429zi, nucleo_f746zg, nucleo_f207zg, nucleo_h753zi

• tests/drivers/spi/spi_loopback:

===================================================================  
START - test_spi_word_size_9  

Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/spi/spi_loopback/src/spi.c:728: spi_loopback_test_word_size: (memcmp(compare_data, rx_buffer, buffer_size) is true)  
9-bit word buffer contents are different  

FAIL - test_spi_word_size_9 in 0.020 seconds  

Platform affected: nucleo_wba55cg

[benedekkupper]

How can I run these tests myself? I have STM32F4 and H7 devices to test on.

If this approach doesn't work out, an alternative would be enabling interrupts in dma_start and disabling in dma_stop only. My question is, how is dma_reload expected to work in the general sense? Currently it also starts the transfer just like dma_start, so it would also need interrupt enabling.

[djiatsaf-st]

How can I run these tests myself? I have STM32F4 and H7 devices to test on.

On Linux with twister:

• ./scripts/twister --device-testing --device-serial /dev/ttyACM0 -p nucleo_h753zi -T tests/drivers/uart/uart_async_api --fixture gpio_loopback

• ./scripts/twister --device-testing --device-serial /dev/ttyACM0 -p nucleo_wba55cg -T tests/drivers/spi/spi_loopback/ --fixture spi_loopback

and check the console output in twister-out /boards_name/scenario_name/handler.log

With west :

west build -p -b nucleo_h753zi tests/drivers/uart/uart_async_api -T drivers.uart.async_api

west build -p -b nucleo_wba55cg tests/drivers/spi/spi_loopback -T drivers.spi.stm32_spi_dma.loopback

---

If this approach doesn't work out, an alternative would be enabling interrupts in dma_start and disabling in dma_stop only. My question is, how is dma_reload expected to work in the general sense? Currently it also starts the transfer just like dma_start, so it would also need interrupt enabling.

From my point of view, dma_reload() should never modify interrupt configuration, it should only refresh buffer parameters and restart the stream. There may be race conditions if reload happens while IRQ handling is in progress.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.