drivers:platform:stm32:dma Circular DMA and Trigger Support

[SwaroopPKADI]

Pull Request Description

Added support for circular DMA using nodes and linked lists, enabling continuous data transfer without manual intervention, which enhances efficiency for repetitive tasks. Additionally, implemented triggering support for DMA, allowing precise control over data transfer initiation based on specific events or conditions

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)

PR Checklist

• I have followed the Coding style guidelines
• I have performed a self-review of the changes
• I have commented my code, at least hard-to-understand parts
• I have build all projects affected by the changes in this PR
• I have tested in hardware affected projects, at the relevant boards
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe etc), if applies

[kister-jimenez]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[SwaroopPKADI]

PR Rev2

• Fixed the astyle issues in stm32_dma.c

[buha]

(I've had this comment in previous contributions to this file regarding the H5 DMA vs other devices' DMA.)

I don't like keeping track of which stm device has which kind of dma and I was assured in the past that there is no way to tell them apart other than by their part name.

But I did some digging and found that ST has 2 types of DMA called Basic DMA or BDMA found in most devices and GPDMA or General Purpose DMA, which is used on more advanced devices and is more capable (notably has these features that you're using here, nodes and list).

I think we could get rid of those #ifdef STM32H5 statements by runtime checking if GPDMA is availabe
#if defined(HAL_GPDMA_MODULE_ENABLED) and modify code accordingly

[SwaroopPKADI]

I verified the HAL as well as the generated files, there is no differentiation between BDMA and GPDMA. Both are enabled using HAL_DMA_MODULE_ENABLED. Even the function name and the handle structure name (DMA_HandleTypeDef) are the same.

Following is my proposal for this:

• Define a macro for GPDMA initially based on the processor macro.
• Use the defined macro to separate functions for GPDMA/BDMA.
• Configure will be divided into 2 parts to configure BDMA and GPDMA separately.

[buha]

Thanks for investigating.

If that's the case, maybe you could create your macro something like this (there must be a base address macro of the GPDMA... or a unique register):

#if defined(GPDMA1) || defined(GPDMA2) || ... whatever max number there can be
    #define GPDMA_AVAILABLE
#endif

Add all these new features in a new file pair called stm32_gpdma.c and protect them with an #ifdef GPDMA_AVAILABLE to be able to build both in all cases. Perhaps you could keep the stm32_dma.h common to both implementations, that would be ideal.