stm32: introduce dma v3 driver #93945

youssefz24 · 2025-07-31T15:16:51Z

Hello there, 🎩

Edit: my wording isn't helping so I wanted to clear out things so no misunderstandings occur.

This PR adds the stm32_dma_v3 driver and support for the HPDMA (using the V3 driver) on the STM32MP257F-EV1 board.

It is inspired from linux version of this driver while maintaining the Zephyr style. (this means that I went through the linux code to understand specifities of the HPDMA, mainly the concept of linked lists that I wasn't familiar with, not that I copied from linux, feel free to compare both logics)

Up to this point, it covers the following tests/samples:

samples/boards/st/uart/circular_dma/", // PASS
samples/drivers/uart/async_api/", // PASS
tests/drivers/dma/chan_blen_transfer", // PASS
tests/drivers/dma/chan_link_transfer", // FAIL
tests/drivers/dma/cyclic", // PASS
tests/drivers/dma/loop_transfer", // PASS
tests/drivers/dma/scatter_gather", // PASS

It uses linked lists when needed in a "dynamic" way (it only updates source and destination address).
The idea is to cover all capabilities of the DMA-V3, some features I am thinking about are:

the channel linking (using triggers)
using the allocated port 1 (depending on conditions)
using padding/alignement
using/preventing packing
FIFO Mode
using transfer queues and fragmenting big transfers with linked lists

Any ideas to include these features are welcome. I ll be waiting for reviews and counseling. 🎩

Signed-off-by: Youssef Zini [email protected]

dts/bindings/dma/st,stm32-dma-v3.yaml

mathieuchopstm

(first comments from non-exhaustive review)

drivers/dma/dma_stm32_v3.c

drivers/dma/dma_stm32_v3.h

dts/bindings/dma/st,stm32-dma-v3.yaml

drivers/dma/dma_stm32_v3.c

youssefz24 · 2025-08-01T16:02:46Z

Update, I rebased, reduced the cognitive complexity in the configure function (solved the issue raised by sonarqube) and made some changes following the first comments.

teburd · 2025-08-19T20:23:32Z

dts/bindings/dma/st,stm32-dma-v3.yaml

+    rx using channel 0 with request 17 for uart5_rx
+    tx using channel 1 with request 18 for uart5_tx
+    uart5 {
+      dmas = <&hpdma3 0 18 (STM32_DMA_PERIPH_TX | STM32_DMA_PRIORITY_HIGH)>,


typically these sorts of dma cells have solely a node reference and channel identifier, maybe a handshake peripheral number. The choice to add bit field options here for linked list, cyclic, or various other modes of operation is interesting but I think gives the illusion that perhaps changing these fields will actually change the way the DMA is used at a peripheral driver level.

Is that actually the intent here? To allow say, a uart to work in linked list or cyclic mode, with 16, 32 or 64bit data words? That doesn't seem logical to me.

That is in fact how we use it - see for example:

zephyr/drivers/spi/spi_ll_stm32.c

Lines 1539 to 1562 in 5c7e12b

#define SPI_DMA_CHANNEL_INIT(index, dir, dir_cap, src_dev, dest_dev) \

.dma_dev = DEVICE_DT_GET(STM32_DMA_CTLR(index, dir)), \

.channel = DT_INST_DMAS_CELL_BY_NAME(index, dir, channel), \

.dma_cfg = { \

.dma_slot = STM32_DMA_SLOT(index, dir, slot),\

.channel_direction = STM32_DMA_CONFIG_DIRECTION( \

STM32_DMA_CHANNEL_CONFIG(index, dir)), \

.source_data_size = STM32_DMA_CONFIG_##src_dev##_DATA_SIZE( \

STM32_DMA_CHANNEL_CONFIG(index, dir)), \

.dest_data_size = STM32_DMA_CONFIG_##dest_dev##_DATA_SIZE( \

STM32_DMA_CHANNEL_CONFIG(index, dir)), \

.source_burst_length = 1, /* SINGLE transfer */ \

.dest_burst_length = 1, /* SINGLE transfer */ \

.channel_priority = STM32_DMA_CONFIG_PRIORITY( \

STM32_DMA_CHANNEL_CONFIG(index, dir)),\

.dma_callback = dma_callback, \

.block_count = 2, \

}, \

.src_addr_increment = STM32_DMA_CONFIG_##src_dev##_ADDR_INC( \

STM32_DMA_CHANNEL_CONFIG(index, dir)), \

.dst_addr_increment = STM32_DMA_CONFIG_##dest_dev##_ADDR_INC( \

STM32_DMA_CHANNEL_CONFIG(index, dir)), \

.fifo_threshold = STM32_DMA_FEATURES_FIFO_THRESHOLD( \

STM32_DMA_FEATURES(index, dir)), \

where all the STM32_DMA_CONFIG_xxx macros come from

zephyr/include/zephyr/drivers/dma/dma_stm32.h

Lines 58 to 86 in 5c7e12b

/* macros for channel-config */

/* enable circular buffer */

#define STM32_DMA_CONFIG_CYCLIC(config) ((config >> 5) & 0x1)

/* direction defined on bits 6-7 */

/* 0 -> MEM_TO_MEM, 1 -> MEM_TO_PERIPH, 2 -> PERIPH_TO_MEM */

#define STM32_DMA_CONFIG_DIRECTION(config) ((config >> 6) & 0x3)

/* periph increment defined on bit 9 as true/false */

#define STM32_DMA_CONFIG_PERIPHERAL_ADDR_INC(config) ((config >> 9) & 0x1)

/* mem increment defined on bit 10 as true/false */

#define STM32_DMA_CONFIG_MEMORY_ADDR_INC(config) ((config >> 10) & 0x1)

/* periph data size defined on bits 11-12 */

/* 0 -> 1 byte, 1 -> 2 bytes, 2 -> 4 bytes */

#define STM32_DMA_CONFIG_PERIPHERAL_DATA_SIZE(config) \

(1 << ((config >> 11) & 0x3))

/* memory data size defined on bits 13, 14 */

/* 0 -> 1 byte, 1 -> 2 bytes, 2 -> 4 bytes */

#define STM32_DMA_CONFIG_MEMORY_DATA_SIZE(config) \

(1 << ((config >> 13) & 0x3))

/* priority increment offset defined on bit 15 */

#define STM32_DMA_CONFIG_PERIPHERAL_INC_FIXED(config) ((config >> 15) & 0x1)

/* priority defined on bits 16-17 as 0, 1, 2, 3 */

#define STM32_DMA_CONFIG_PRIORITY(config) ((config >> 16) & 0x3)

/* macro for features (only for dma-v1) */

#if DT_HAS_COMPAT_STATUS_OKAY(st_stm32_dma_v1)

#define STM32_DMA_FEATURES_FIFO_THRESHOLD(features) (features & 0x3)

#else

#define STM32_DMA_FEATURES_FIFO_THRESHOLD(features) 0

#endif

These being unpackers of the values encoded by the bindings header:
https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/dt-bindings/dma/stm32_dma.h
(that could use a good cleanup...)

You are raising an interesting point though, in the sense that it is up to the DMA user to actually consume these values (i.e., these only work because drivers do consume the values - they are not automagically injected in the dma_config). The corollary question is: without this cell, how is one supposed to customize the DMA configuration when it is used by another device driver? Is there a generic method for this that the ST drivers should implement?

Also, at least some of these parameters could be hardcoded in drivers, e.g. the DMA used for UART TX will always be memory->peripheral; I'm going off-topic with this though...

That's my point, the uart driver is going to configure the DMA for how it wishes to use it, having these fields here is confusing and would imply to someone configuring their device that these are options that can be changed for say... how the uart driver may use the DMA, but is that really the case? Can I change say how the st uart driver uses DMA to use the linked list descriptors or cyclic buffer mode? That would, I think, be a very different looking driver.

So what you re asking for is either get the uart driver to actually be able to use Linked Lists, (I don t see the use of having 32bits transfers as the hardware will only transfer 8 anyways), and remove all the unused parameters from the dts binding ?

Then again how would you have a custom configuration for Hardware transfer requests ?

I'm saying don't provide bits in DTS defines that don't make sense from a user configuration perspective, as that's what it is. It's user configurable. If a driver wishes to set word sizing, linked list or cyclic, what the watermark would be, etc etc for a DMA transfer that's entirely up to the driver using the peripheral to do this. Otherwise what I'd expect is that a poor user comes along, sees that ST supports linked list transfers or cyclic transfers with their DMA and any peripheral, only to confusingly either break the peripheral driver or be silently ignored. Either of those outcomes is a poor user experience for someone setting up their devicetree.

That's my point, the uart driver is going to configure the DMA for how it wishes to use it, having these fields here is confusing and would imply to someone configuring their device that these are options that can be changed for say... how the uart driver may use the DMA, but is that really the case? Can I change say how the st uart driver uses DMA to use the linked list descriptors or cyclic buffer mode? That would, I think, be a very different looking driver.

It seems to be the case, actually: DMA configuration cyclic depends on DT property

zephyr/drivers/serial/uart_stm32.c

Lines 2377 to 2378 in 9135918

.cyclic = STM32_DMA_CONFIG_CYCLIC( \

STM32_DMA_CHANNEL_CONFIG(index, dir)), \

and the driver checks whether it's enabled or not during its operation:

zephyr/drivers/serial/uart_stm32.c

Lines 1162 to 1173 in 9135918

/* When cyclic DMA is used, buffer positions are not updated - call callback every time*/

if (data->dma_rx.dma_cfg.cyclic == 0) {

/* update the current pos for new data */

data->dma_rx.offset = data->dma_rx.counter;

/* send event only for new data */

if (event.data.rx.len > 0) {

async_user_callback(data, &event);

}

} else {

async_user_callback(data, &event);

}

Whether all drivers support all use cases is another question but there are at least some drivers that consume some options to affect their behavior.

(+ I don't remember the exact DMA API, but as far as I understand, whether a DMA transfer is done with a "direct" programming or a linked list should be an implementation detail of the DMA driver?)

whether a DMA transfer is done with a "direct" programming or a linked list should be an implementation detail of the DMA driver?

It seems that it is up to the driver to use one of the two, but that is depending on the usage/configuration.
The DMA struct from Zephyr enables the use of chained blocks, so one way is saying if you have more than one block to configure linked lists, one can also juste configure a said channel for a transfer and call the reload function to do another transfer in direct programming with changing only the addresses, having the same effect with only direct programming.

So I d say the usage of linked lists or direct programmign depends on how the user side uses the DMA API and its structure.

In my case I tried exposing all the ways depending on the available tests. Si linked lists are used with cyclic and scatter gather tests as they need multiple transfers. and it is better to do so fully with DMA rather than call the CPU at each end of transfer.

Either way, some of the symbols I added in the yaml are in fact not consumable so far so I guess I ll just remove them for next batch and add them only when that s the case. :D

@teburd PTAL :p

drivers/dma/dma_stm32_v3.h

teburd · 2025-08-19T20:27:13Z

drivers/dma/dma_stm32_v3.c

+		return 0;
+	}
+
+	if (!LL_DMA_IsEnabledChannel(dma, channel)) {


If the channel is enabled or not, stop is allowable. See the DMA state diagram in driver expectations https://docs.zephyrproject.org/latest/hardware/peripherals/dma.html#driver-implementation-expectations

The way I see this, the "LL_DMA_IsEnabledChannel" is more like a not running state as it is only changed after a dma_stm32_start call.

So in this regard, it returns a 0 early when trying to stop before a start was called (just after configuration for example as it is done in the loop_transfer test). Removing this early exit will cause the stop function to actually disable the channel, making it fail to start.

drivers/dma/dma_stm32_v3.c

arnopo · 2025-09-08T09:43:48Z

drivers/dma/dma_stm32_v3.c

+};
+
+struct dma_stm32_data {
+	struct dma_context dma_ctx;


quite strange to me a structure that integrates a single field?
Any reason to not directly use struct dma_context

Looking around other drivers zephyr/drivers/dma/dma_nxp_sdma.c, zephyr/drivers/dma/dma_mcux_edma.c, zephyr/drivers/dma/dma_intel_adsp_hda.h ... they all have a "data" structure with the context, "atomic channel" which i m not sure what is it used for and even the channel pool for LLIs. so i just made it a structure in case.
Also in the zephyr/include/zephyr/drivers/dma.h line 296:

/** * DMA context structure * Note: the dma_context shall be the first member * of DMA client driver Data, got by dev->data */

So yeah I just made it in the data structure. should i remove it and use it directly ?

drivers/dma/dma_stm32_v3.c

arnopo · 2025-09-08T09:50:11Z

drivers/dma/dma_stm32_v3.c

+static inline DMA_Channel_TypeDef *dma_stm32_get_channel_addr(DMA_TypeDef *dma,
+							      uint32_t channel)
+{
+	return (DMA_Channel_TypeDef *)((uint32_t)dma + LL_DMA_CH_OFFSET_TAB[channel]);


no check needed on channel value?

The check is already done by the calling functions. Should I add a check here to make sure it is a valid channel again ?

drivers/dma/dma_stm32_v3.c

teburd · 2025-09-08T13:03:32Z

I still generally disagree with this idea that you should be configuring how DMA (linked list, cyclic, etc) is used with common DMA bit flags here, and instead provide peripheral attributes for this. But I'm not going to block over this.

drivers/dma/dma_stm32_v3.c

ADESTM · 2025-09-10T13:35:33Z

drivers/dma/dma_stm32_v3.c

+		hwdesc.channel_tr2 |= LL_DMA_TCEM_BLK_TRANSFER;
+	} else {
+		hwdesc.channel_tr2 |= LL_DMA_TCEM_EACH_LLITEM_TRANSFER;
+	}


LL_DMA_TCEM_BLK_TRANSFER and LL_DMA_TCEM_EACH_LLITEM_TRANSFER are rather the same in term of transfer status: none of them indicates the end of the whole transfer.
LL_DMA_TCEM_BLK_TRANSFER triggers TC event each time CxBR1.BNDT=0,
LL_DMA_TCEM_EACH_LLITEM_TRANSFER triggers TC event each time the next LLI (if any) is loaded after CxBR1.BNDT=0.

ADESTM · 2025-09-10T13:37:07Z

drivers/dma/dma_stm32_v3.c

+
+	if (ll_direction != LL_DMA_DIRECTION_MEMORY_TO_MEMORY) {
+		LL_DMA_SetPeriphRequest(dma, channel, config->dma_slot);
+	}


CxTR2.SWREQ have to be set in case of LL_DMA_DIRECTION_MEMORY_TO_MEMORY.

It is set by the direction parameter.
the descriptor hwdesc.channel_tr2 holds the ll_direction which in turn is defined as either:

LL_DMA_DIRECTION_MEMORY_TO_MEMORY LL_DMA_DIRECTION_PERIPH_TO_MEMORY LL_DMA_DIRECTION_MEMORY_TO_PERIPH

In the hal file these represent masks to set/clear DMA_CTR2_SWREQ and DMA_CTR2_DREQ.
So SWREQ is actually being set for the case LL_DMA_DIRECTION_MEMORY_TO_MEMORY

dts/arm/st/mp2/stm32mp2_m33.dtsi

ADESTM · 2025-09-10T14:39:50Z

drivers/dma/dma_stm32_v3.c

+	}
+
+	LL_DMA_EnableIT_HT(dma, channel);
+}


All blocks have the same length (no CBR1 update) ?

Why do you enable half transfer interrupt ?

So far I presume all blocks have the same size and I only update the source and destination addresses. That's why there is no CBR1 update.
I know I should check for all changes block by block but since I based this on the tests available, this was enough to validate them.

avolmat-st · 2025-09-10T16:15:35Z

Hello,
jumping a bit late in this conversation.
Maybe I missed an important point, but there is already within Zephyr a driver for the GPDMA of the STM32U5 which can be found in drivers/dma/dma_stm32u5.c. Considering that normally LPDMA / GPDMA / HPDMA are very close, can't this driver be used as a starting point to add any potential missing bits ?

ADESTM · 2025-09-10T16:52:17Z

Hello, jumping a bit late in this conversation. Maybe I missed an important point, but there is already within Zephyr a driver for the GPDMA of the STM32U5 which can be found in drivers/dma/dma_stm32u5.c. Considering that normally LPDMA / GPDMA / HPDMA are very close, can't this driver be used as a starting point to add any potential missing bits ?

Indeed, at the hardware level, I confirm that the operation of LPDMA, GPDMA, and HPDMA is identical: they use the same registers and bitfields. HPDMA is an extension of GPDMA, which itself extends LPDMA. So a GPDMA driver is compatible with a HPDMA hardware.

etienne-lms

Some minor comments.

etienne-lms · 2025-09-03T16:32:50Z

drivers/dma/dma_stm32_v3.c

+static inline DMA_Channel_TypeDef *dma_stm32_get_channel_addr(DMA_TypeDef *dma,
+							      uint32_t channel)
+{
+	return (DMA_Channel_TypeDef *)((uint32_t)dma + LL_DMA_CH_OFFSET_TAB[channel]);


Prefer a cast to uintptr_t instead of uint32_t?

etienne-lms · 2025-09-16T07:10:44Z

drivers/dma/dma_stm32_v3.c

+	sys_clear_bits(dma_channel_ccr_reg, DMA_CCR_TCIE | DMA_CCR_HTIE | DMA_CCR_USEIE |
+						    DMA_CCR_ULEIE | DMA_CCR_DTEIE | DMA_CCR_SUSPIE);


These were run though the clang format :/

etienne-lms · 2025-09-16T07:11:41Z

drivers/dma/dma_stm32_v3.c

+	sys_set_bits(dma_channel_cfcr_reg, DMA_CFCR_TCF | DMA_CFCR_HTF | DMA_CFCR_DTEF |
+						   DMA_CFCR_ULEF | DMA_CFCR_USEF | DMA_CFCR_TOF |
+						   DMA_CFCR_SUSPF);


Indentation: remove a tab.

These were run though the clang format :/

Strange, indentation is weird here :-(

etienne-lms · 2025-09-16T07:18:04Z

drivers/dma/dma_stm32_v3.c

+{
+	const struct dma_stm32_config *dev_config = dev->config;
+	struct dma_stm32_channel *channel_config;
+	uint32_t channel = dma_stm32_id_to_channel(id);


Check id < Check id < id >= dev_config->max_channels??
Ditto in dma_stm32_stop().

I added checks for the start stop and status functions.
Not the IRQ handler since it is supposed to do the least ops possible (it already runs a bunch of if tests)

Not the IRQ handler since it is supposed to do the least ops possible (it already runs a bunch of if tests)

Agree.

etienne-lms · 2025-09-16T07:22:40Z

drivers/dma/dma_stm32_v3.c

+		COND_CODE_1(DT_NODE_HAS_PROP(__node, clocks),                                      \
+			    (.pclken = { .bus = __bus, .enr = __cenr },),                          \
+			    (/* Nothing if clocks not present */))                                 \
+			.config_irq = dma_stm32_config_irq_##index,                                \


Indentation

Suggested change

.config_irq = dma_stm32_config_irq_##index, \

.config_irq = dma_stm32_config_irq_##index, \

etienne-lms · 2025-09-16T07:24:03Z

drivers/dma/dma_stm32_v3.c

+		.max_channels =                                                                    \
+			DT_INST_PROP_OR(index, dma_channels, DT_NUM_IRQS(DT_DRV_INST(index))),     \
+		.channels = dma_stm32_channels_##index,                                            \
+		.linked_list_buffer = dma_stm32_linked_list_buffer##index};                        \


For consistency, prefer:

Suggested change

.linked_list_buffer = dma_stm32_linked_list_buffer##index}; \

.linked_list_buffer = dma_stm32_linked_list_buffer##index, \

}; \

dts/arm/st/mp2/stm32mp2_m33.dtsi

etienne-lms · 2025-09-16T07:32:02Z

drivers/dma/dma_stm32_v3.c

+	channel = dma_stm32_id_to_channel(id);
+	LL_DMA_SetLinkedListBaseAddr(dma, channel, base_addr);
+
+	for (int i = 0; i < config->block_count; i++) {


Prefer use type uint since block_count is unsigned. Would prefer some compiler to complain on signed/unsigned comparison.

erwango · 2025-09-16T08:40:56Z

Hello,
jumping a bit late in this conversation.
Maybe I missed an important point, but there is already within Zephyr a driver for the GPDMA of the STM32U5 which can be found in drivers/dma/dma_stm32u5.c. Considering that normally LPDMA / GPDMA / HPDMA are very close, can't this driver be used as a starting point to add any potential missing bits ?

Thanks @avolmat-st for raising this point. I agree that rather than duplicating a driver we'd better work on cleaning/completing the existing one.
@youssefz24 Based on the work you made for this PR, would you mind having a check on drivers/dma/dma_stm32u5.c and see what would be required to make it work on MP2 ? I'd prefer we work on consolidating the existing and minimize duplication, and I guess there is potential for improvement in many ways (like making it clear which IP are concerned, which obviously we're failing at today)

Add compatible yaml file for stm32 dma v3 controllers. This is compatible with the HPDMA and LPDMA controllers in the STM32MP2 series Socs. Signed-off-by: Youssef Zini <[email protected]>

Since the STM32MP2 series supports a new DMA peripheral (HPDMA and LPDMA), this commit introduces a new driver for the STM32 DMA v3. So far, it includes basic functionality for the HPDMA channels, enabling the use of async APIs (tested using uart on the STM32MP257F-EV1 board), as well as support circular dma and loop transfers (reload mode and suspend/resume). The driver is designed to be compatible with the existing Zephyr DMA API, while being inspired heavily by the linux stm32 dma3 driver[1]. The classes and functions used are thought to allow for easy linked list operations in the future, as well as support scatter gather, cyclic transfers and channel linking. [1]: https://github.com/STMicroelectronics/linux/blob/v6.6-stm32mp/drivers/dma/stm32/stm32-dma3.c Signed-off-by: Youssef Zini <[email protected]>

Add support for the new DMA v3 driver in the STM32 series uart async API. Signed-off-by: Youssef Zini <[email protected]>

Add dma v3 symbols to Kconfig.stm32 to enable support when dma v3 is used in the device tree. Also add the new driver reference in the CMakeLists.txt file. Signed-off-by: Youssef Zini <[email protected]>

Add parentheses to macros in drivers and dt-bindings stm32 dma files to avoid potential issues with operator precedence when these macros are used in expressions. Signed-off-by: Youssef Zini <[email protected]>

Add the clock bindings for the stm32mp2 dmas, HPDMA(1-3) and LPDMA1. Signed-off-by: Youssef Zini <[email protected]>

Add a new HPDMA3 node to the STM32MP2 M33 device tree. With the current configuration, the Cortex-M33 can only use the HPDMA3 channels 0 to 13. Signed-off-by: Youssef Zini <[email protected]>

Add dma as a supported driver in the STM32MP257F-EV1 board YAML file. Signed-off-by: Youssef Zini <[email protected]>

Add stm32mp257f_ev1 overlay for uart async API and circular_dma samples using uart5 with HPDMA3 channels 0 and 1 for TX and RX respectively. Signed-off-by: Youssef Zini <[email protected]>

Add stm32mp257f_ev1 overlays and related configuration files for the DMA tests. This includes support for: * chan_blen_transfer * cyclic * loop_transfer * scatter_gather Add stm32mp257f_ev1/stm32mp257fxx/m33 to the platform_allow list. Signed-off-by: Youssef Zini <[email protected]>

Add support for linked list items (LLI) in the STM32 DMA v3 driver. This allows for more flexible DMA configurations, such as scatter-gather and cyclic transfers. This allows to pass both the dma_m2m_cyclic and the dma_m2m_sg tests on the stm32mp257f_ev1 board. Signed-off-by: Youssef Zini <[email protected]>

sonarqubecloud · 2025-09-16T09:23:17Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

zephyrbot added area: UART Universal Asynchronous Receiver-Transmitter area: DMA Direct Memory Access platform: STM32 ST Micro STM32 area: Samples Samples area: Clock Control labels Jul 31, 2025

zephyrbot requested review from dcpleung, djiatsaf-st, erwango, etienne-lms, FRASTM, gautierg-st, GeorgeCGV, kartben, marwaiehm-st, mathieuchopstm, nashif, nordic-krch and teburd July 31, 2025 15:17

zephyrbot assigned teburd Jul 31, 2025

JarmouniA changed the title ~~Topic/stm32/dma v3~~ stm32: introduce dma v3 driver Jul 31, 2025

JarmouniA reviewed Jul 31, 2025

View reviewed changes

dts/bindings/dma/st,stm32-dma-v3.yaml Show resolved Hide resolved

JarmouniA added the Licensing The PR has licensing issues => licensing expert to review label Jul 31, 2025

mathieuchopstm reviewed Aug 1, 2025

View reviewed changes

youssefz24 force-pushed the topic/stm32/dma_v3 branch from e9e4541 to 12b871e Compare August 1, 2025 15:27

teburd requested changes Aug 19, 2025

View reviewed changes

youssefz24 force-pushed the topic/stm32/dma_v3 branch 4 times, most recently from d5f6d4e to fc2c508 Compare August 22, 2025 16:10

youssefz24 force-pushed the topic/stm32/dma_v3 branch from deae80b to 0b2086f Compare September 3, 2025 13:29

JarmouniA removed the Licensing The PR has licensing issues => licensing expert to review label Sep 6, 2025

arnopo reviewed Sep 8, 2025

View reviewed changes

teburd previously approved these changes Sep 8, 2025

View reviewed changes

ADESTM reviewed Sep 10, 2025

View reviewed changes

drivers/dma/dma_stm32_v3.c Outdated Show resolved Hide resolved

ADESTM reviewed Sep 10, 2025

View reviewed changes

dts/arm/st/mp2/stm32mp2_m33.dtsi Show resolved Hide resolved

ADESTM reviewed Sep 10, 2025

View reviewed changes

avolmat-st self-requested a review September 10, 2025 19:05

etienne-lms reviewed Sep 16, 2025

View reviewed changes

youssefz24 added 11 commits September 16, 2025 10:57

bindings/dma/st,stm32-dma-v3.yaml: add compatible

ecb131a

Add compatible yaml file for stm32 dma v3 controllers. This is compatible with the HPDMA and LPDMA controllers in the STM32MP2 series Socs. Signed-off-by: Youssef Zini <[email protected]>

drivers/serial/Kconfig.stm32: add dma v3 support

d213a07

Add support for the new DMA v3 driver in the STM32 series uart async API. Signed-off-by: Youssef Zini <[email protected]>

drivers/dma/Kconfig.stm32: add dma v3 support

814228d

Add dma v3 symbols to Kconfig.stm32 to enable support when dma v3 is used in the device tree. Also add the new driver reference in the CMakeLists.txt file. Signed-off-by: Youssef Zini <[email protected]>

include/zephyr: dma stm32: add macro parentheses

8c108e9

Add parentheses to macros in drivers and dt-bindings stm32 dma files to avoid potential issues with operator precedence when these macros are used in expressions. Signed-off-by: Youssef Zini <[email protected]>

include/zephyr/dt-bindings: add stm32mp2 dma clock

8142991

Add the clock bindings for the stm32mp2 dmas, HPDMA(1-3) and LPDMA1. Signed-off-by: Youssef Zini <[email protected]>

dts/arm/st/mp2/stm32mp2_m33.dtsi: add hpdma3 node

e318d74

Add a new HPDMA3 node to the STM32MP2 M33 device tree. With the current configuration, the Cortex-M33 can only use the HPDMA3 channels 0 to 13. Signed-off-by: Youssef Zini <[email protected]>

boards/st/stm32mp257f_ev1: add dma to board yaml

c317ef1

Add dma as a supported driver in the STM32MP257F-EV1 board YAML file. Signed-off-by: Youssef Zini <[email protected]>

samples/drivers/uart: add stm32mp257f_ev1 overlay

7254eb3

Add stm32mp257f_ev1 overlay for uart async API and circular_dma samples using uart5 with HPDMA3 channels 0 and 1 for TX and RX respectively. Signed-off-by: Youssef Zini <[email protected]>

youssefz24 dismissed teburd’s stale review via c89e089 September 16, 2025 08:58

youssefz24 force-pushed the topic/stm32/dma_v3 branch from 0b2086f to c89e089 Compare September 16, 2025 08:58

zephyrbot requested a review from teburd September 16, 2025 09:00

	#define SPI_DMA_CHANNEL_INIT(index, dir, dir_cap, src_dev, dest_dev) \
	.dma_dev = DEVICE_DT_GET(STM32_DMA_CTLR(index, dir)), \
	.channel = DT_INST_DMAS_CELL_BY_NAME(index, dir, channel), \
	.dma_cfg = { \
	.dma_slot = STM32_DMA_SLOT(index, dir, slot),\
	.channel_direction = STM32_DMA_CONFIG_DIRECTION( \
	STM32_DMA_CHANNEL_CONFIG(index, dir)), \
	.source_data_size = STM32_DMA_CONFIG_##src_dev##_DATA_SIZE( \
	STM32_DMA_CHANNEL_CONFIG(index, dir)), \
	.dest_data_size = STM32_DMA_CONFIG_##dest_dev##_DATA_SIZE( \
	STM32_DMA_CHANNEL_CONFIG(index, dir)), \
	.source_burst_length = 1, /* SINGLE transfer */ \
	.dest_burst_length = 1, /* SINGLE transfer */ \
	.channel_priority = STM32_DMA_CONFIG_PRIORITY( \
	STM32_DMA_CHANNEL_CONFIG(index, dir)),\
	.dma_callback = dma_callback, \
	.block_count = 2, \
	}, \
	.src_addr_increment = STM32_DMA_CONFIG_##src_dev##_ADDR_INC( \
	STM32_DMA_CHANNEL_CONFIG(index, dir)), \
	.dst_addr_increment = STM32_DMA_CONFIG_##dest_dev##_ADDR_INC( \
	STM32_DMA_CHANNEL_CONFIG(index, dir)), \
	.fifo_threshold = STM32_DMA_FEATURES_FIFO_THRESHOLD( \
	STM32_DMA_FEATURES(index, dir)), \

	/* macros for channel-config */
	/* enable circular buffer */
	#define STM32_DMA_CONFIG_CYCLIC(config) ((config >> 5) & 0x1)
	/* direction defined on bits 6-7 */
	/* 0 -> MEM_TO_MEM, 1 -> MEM_TO_PERIPH, 2 -> PERIPH_TO_MEM */
	#define STM32_DMA_CONFIG_DIRECTION(config) ((config >> 6) & 0x3)
	/* periph increment defined on bit 9 as true/false */
	#define STM32_DMA_CONFIG_PERIPHERAL_ADDR_INC(config) ((config >> 9) & 0x1)
	/* mem increment defined on bit 10 as true/false */
	#define STM32_DMA_CONFIG_MEMORY_ADDR_INC(config) ((config >> 10) & 0x1)
	/* periph data size defined on bits 11-12 */
	/* 0 -> 1 byte, 1 -> 2 bytes, 2 -> 4 bytes */
	#define STM32_DMA_CONFIG_PERIPHERAL_DATA_SIZE(config) \
	(1 << ((config >> 11) & 0x3))
	/* memory data size defined on bits 13, 14 */
	/* 0 -> 1 byte, 1 -> 2 bytes, 2 -> 4 bytes */
	#define STM32_DMA_CONFIG_MEMORY_DATA_SIZE(config) \
	(1 << ((config >> 13) & 0x3))
	/* priority increment offset defined on bit 15 */
	#define STM32_DMA_CONFIG_PERIPHERAL_INC_FIXED(config) ((config >> 15) & 0x1)
	/* priority defined on bits 16-17 as 0, 1, 2, 3 */
	#define STM32_DMA_CONFIG_PRIORITY(config) ((config >> 16) & 0x3)

	/* macro for features (only for dma-v1) */
	#if DT_HAS_COMPAT_STATUS_OKAY(st_stm32_dma_v1)
	#define STM32_DMA_FEATURES_FIFO_THRESHOLD(features) (features & 0x3)
	#else
	#define STM32_DMA_FEATURES_FIFO_THRESHOLD(features) 0
	#endif

	.cyclic = STM32_DMA_CONFIG_CYCLIC( \
	STM32_DMA_CHANNEL_CONFIG(index, dir)), \

	/* When cyclic DMA is used, buffer positions are not updated - call callback every time*/
	if (data->dma_rx.dma_cfg.cyclic == 0) {
	/* update the current pos for new data */
	data->dma_rx.offset = data->dma_rx.counter;

	/* send event only for new data */
	if (event.data.rx.len > 0) {
	async_user_callback(data, &event);
	}
	} else {
	async_user_callback(data, &event);
	}

		sys_clear_bits(dma_channel_ccr_reg, DMA_CCR_TCIE \| DMA_CCR_HTIE \| DMA_CCR_USEIE \|
		DMA_CCR_ULEIE \| DMA_CCR_DTEIE \| DMA_CCR_SUSPIE);

	.config_irq = dma_stm32_config_irq_##index, \
	.config_irq = dma_stm32_config_irq_##index, \

stm32: introduce dma v3 driver #93945

Are you sure you want to change the base?

stm32: introduce dma v3 driver #93945

Conversation

youssefz24 commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

mathieuchopstm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

youssefz24 commented Aug 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mathieuchopstm Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

teburd commented Sep 8, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

avolmat-st commented Sep 10, 2025

Uh oh!

ADESTM commented Sep 10, 2025

Uh oh!

etienne-lms left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

youssefz24 commented Jul 31, 2025 •

edited

Loading

mathieuchopstm Aug 20, 2025 •

edited

Loading