Re: [EXT] Re: about DMA API updates proposal

Hake Huang

Hi Gala,

I will create a separated PR for DMA new API only.

and one question for below:
"use some of the generic devicetree properties in "dts/bindings/dma/dma-controller.yaml”. The number space allocation code seems pretty generic"

Do you mean, instead of just add API call but move below implement to common code?

static int dma_mcux_edma_request_channel(const struct device *dev,
enum dma_channel_filter filter)
int i = 0;
int channel = -EINVAL;

k_mutex_lock(&DEV_DATA(dev)->dma_mutex, K_FOREVER);

for (i = 0; i < DEV_CFG(dev)->dma_channels; i++) {
/* channel 0-3 is Period trigger enabled */
if (filter == DMA_CHANNEL_PERIODIC && i > 3) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i)) {
channel = i;


return channel;

If so the filter is hard to aligned, as different SOC has different filter setting.


-----Original Message-----
From: Kumar Gala <>
Sent: 2021年3月3日 1:43
To: Hake Huang <>
Cc:; Maureen Helm <>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <> wrote:

Hi All,

I am working on enable NXP EDMA drivers to Zephyr DMA framework, and I have two DMA API changes need to discussion.
in this PR, I add chain_link by using the dest_chaining_en(Major) and source_chaining_en(minor).
reserved=0 in this PR,
.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wp3iDOFIDkcsLjHRqk9OMWe3yiDfBXko6SHkIDrjQeA%3D&amp;reserved=0 two helper APIs is added dma_api_request_channel request_channel; dma_api_release_channel release_channel; the two APIs are for DMA engine which is capable to dynamically allocate its channels to different DMA requests. and a filter is also added in case of special DMA channel features.

Slack topic discussion is here

Can this topic be scheduled in next API meeting? Thanks.

I wonder if we should pull this into a separate PR. I think a fair amount of the code for these APIs could be generic.

For example I think we can use some of the generic devicetree properties in "dts/bindings/dma/dma-controller.yaml”. The number space allocation code seems pretty generic, even if it just library code used by all the drivers.

- k

Join to automatically receive all group messages.