Topics

[EXT] about DMA API updates proposal


Kumar Gala
 

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle. I’m curious if other vendors have channels that have specific features like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F28895&;data=04%7C01%7Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637028957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qvzAFWPYl0UqMQ1EXwcLV8RsfZafClxs5BqVRVjGwJE%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major) and source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7C01%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D&amp;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F25e19f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%40nxp
.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.


Regards,
Hake
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





Hake Huang
 

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We will have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not periodic, then we have to use if else instead of a simple call with filter.

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev) dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev) mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle. I’m curious if other vendors have channels that have specific features like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F28895&;data=04%7C01%7Chake.huang%40nxp.com%7C7badf36a6bf5455b761208d8de538ed3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637503797754222166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3Wt4goDCCflaV%2BPYFBdNREsTkriiSOx97R719Obdxcw%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major) and source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7C01
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpb
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D&am
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F25e1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%40n
xp
.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.


Regards,
Hake
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





Kumar Gala
 

1. I think we handle that on a case by case basis and wait and see how it develops over time. If we keep these APIs vendor specific for now we can refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or the caller.

The concern I have is we don’t know what kinda of ‘filters’ we need today beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We will have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not periodic, then we have to use if else instead of a simple call with filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev) dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev) mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle. I’m curious if other vendors have channels that have specific features like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F28895&;data=04%7C01%7Chake.huang%40nxp.com%7C7badf36a6bf5455b761208d8de538ed3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637503797754222166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3Wt4goDCCflaV%2BPYFBdNREsTkriiSOx97R719Obdxcw%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major) and source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7C01
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpb
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D&am
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F25e1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%40n
xp
.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.


Regards,
Hake
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





Hake Huang
 

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://docs.huihoo.com/doxygen/linux/kernel/3.7/dmatest_8c_source.html
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan->device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter, so the zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void * filter_param)
{
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i)) {
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no filter then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see how it develops over time. If we keep these APIs vendor specific for now we can refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or the caller.

The concern I have is we don’t know what kinda of ‘filters’ we need today beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We will have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not periodic, then we have to use if else instead of a simple call with filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle. I’m curious if other vendors have channels that have specific features like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F28895&;data=04%7C01%7Chake.huang%40nxp.com%7C9fe84a29cebc431a0e6508d8df1e396a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637504668195258425%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1cYqN9yxrA7SDpGLRLLic%2FIvj4I679VkYcaFm8LHIl0%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major) and source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F25e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%40
n
xp
.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.


Regards,
Hake
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





Hake Huang
 

Hi Gala,

I create a new PR https://github.com/zephyrproject-rtos/zephyr/pull/33174 dedicated for the two new APIS, please check. Thanks in advance.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月5日 11:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://docs.huihoo.com/doxygen/linux/kernel/3.7/dmatest_8c_source.html
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan->device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter, so the zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void * filter_param) {
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i)) {
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no filter then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see how it develops over time. If we keep these APIs vendor specific for now we can refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or the caller.

The concern I have is we don’t know what kinda of ‘filters’ we need today beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We will have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not periodic, then we have to use if else instead of a simple call with filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle. I’m curious if other vendors have channels that have specific features like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F28895&;data=04%7C01%7Chake.huang%40nxp.com%7C9fe84a29cebc431a0e6508d8df1e396a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637504668195258425%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1cYqN9yxrA7SDpGLRLLic%2FIvj4I679VkYcaFm8LHIl0%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major) and source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F25e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%40
n
xp
.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.


Regards,
Hake
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





Carles Cufi
 

Hi Hake,

Is this something you want to discuss at the API meeting today? It's at 18h CET.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Hake Huang via lists.zephyrproject.org
Sent: 09 March 2021 12:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>;
Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I create a new PR
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F33174&amp;data=04%7C01%7Ccarles.cufi%40nordicsemi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C
0%7C0%7C637508879620655760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xJlwTcev57aEZ
bDlldIUODWfUpNLzH7SbIUnbTvqMNw%3D&amp;reserved=0 dedicated for the two new
APIS, please check. Thanks in advance.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月5日 11:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>;
Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.hui
hoo.com%2Fdoxygen%2Flinux%2Fkernel%2F3.7%2Fdmatest_8c_source.html&amp;data
=04%7C01%7Ccarles.cufi%40nordicsemi.no%7C2f7fefddf3df4385a77008d8e2f26416%
7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637508879620665756%7CUnknown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
Mn0%3D%7C3000&amp;sdata=Sq5QarVur4smW1zz1sWY6nRBMwca2lCnzmMVW9Z9kNI%3D&amp
;reserved=0
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan-
device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter, so the
zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void *
filter_param) {
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i))
{
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no filter
then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>;
Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see how it
develops over time. If we keep these APIs vendor specific for now we can
refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or the
caller.

The concern I have is we don’t know what kinda of ‘filters’ we need today
beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We will
have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not
periodic, then we have to use if else instead of a simple call with
filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org
<kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle. I’m
curious if other vendors have channels that have specific features like
‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F28895&amp;data=04%7C01%7Ccarles.cufi%40nordicsemi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C
0%7C0%7C637508879620665756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HpXjVqCHdnoRg
IbGlttgT2pLgUWUr%2Fx3oaLgsR479F4%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major) and
source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F25e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%40
n
xp
.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c301635
%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wp3iDOFIDk
csLjHRqk9OMWe3yiDfBXko6SHkIDrjQeA%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.


Regards,
Hake
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








Kumar Gala
 

I can present the two options that Hake and I have discussed in this thread to see if there’s any feedback on which direction to take for the new API that is being suggested.

(Happy to do this so Hake doesn’t have to be awake at a crazy hour for him).

- k

On Mar 9, 2021, at 6:17 AM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Hake,

Is this something you want to discuss at the API meeting today? It's at 18h CET.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Hake Huang via lists.zephyrproject.org
Sent: 09 March 2021 12:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>;
Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I create a new PR
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F33174&amp;data=04%7C01%7Ccarles.cufi%40nordicsemi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C
0%7C0%7C637508879620655760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xJlwTcev57aEZ
bDlldIUODWfUpNLzH7SbIUnbTvqMNw%3D&amp;reserved=0 dedicated for the two new
APIS, please check. Thanks in advance.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月5日 11:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>;
Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.hui
hoo.com%2Fdoxygen%2Flinux%2Fkernel%2F3.7%2Fdmatest_8c_source.html&amp;data
=04%7C01%7Ccarles.cufi%40nordicsemi.no%7C2f7fefddf3df4385a77008d8e2f26416%
7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637508879620665756%7CUnknown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
Mn0%3D%7C3000&amp;sdata=Sq5QarVur4smW1zz1sWY6nRBMwca2lCnzmMVW9Z9kNI%3D&amp
;reserved=0
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan-
device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter, so the
zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void *
filter_param) {
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels, i))
{
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no filter
then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>;
Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see how it
develops over time. If we keep these APIs vendor specific for now we can
refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or the
caller.

The concern I have is we don’t know what kinda of ‘filters’ we need today
beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We will
have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not
periodic, then we have to use if else instead of a simple call with
filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org
<kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle. I’m
curious if other vendors have channels that have specific features like
‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F28895&amp;data=04%7C01%7Ccarles.cufi%40nordicsemi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C
0%7C0%7C637508879620665756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HpXjVqCHdnoRg
IbGlttgT2pLgUWUr%2Fx3oaLgsR479F4%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major) and
source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F25e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%40
n
xp
.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c301635
%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wp3iDOFIDk
csLjHRqk9OMWe3yiDfBXko6SHkIDrjQeA%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.


Regards,
Hake
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








Hake Huang
 

Thanks Gala. Really appreciated.

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月9日 21:31
To: Carles Cufi <Carles.Cufi@nordicsemi.no>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

I can present the two options that Hake and I have discussed in this thread to see if there’s any feedback on which direction to take for the new API that is being suggested.

(Happy to do this so Hake doesn’t have to be awake at a crazy hour for him).

- k

On Mar 9, 2021, at 6:17 AM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Hake,

Is this something you want to discuss at the API meeting today? It's at 18h CET.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Hake Huang via lists.zephyrproject.org
Sent: 09 March 2021 12:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I create a new PR
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F33174&amp;data=04%7C01%7Ccarles.cufi%40nordics
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e
8d%7C
0%7C0%7C637508879620655760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xJlwTcev
57aEZ
bDlldIUODWfUpNLzH7SbIUnbTvqMNw%3D&amp;reserved=0 dedicated for the
two new APIS, please check. Thanks in advance.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月5日 11:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
s.hui
hoo.com%2Fdoxygen%2Flinux%2Fkernel%2F3.7%2Fdmatest_8c_source.html&amp
;data
=04%7C01%7Ccarles.cufi%40nordicsemi.no%7C2f7fefddf3df4385a77008d8e2f2
6416%
7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637508879620665756%7CUnk
nown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
XVCI6
Mn0%3D%7C3000&amp;sdata=Sq5QarVur4smW1zz1sWY6nRBMwca2lCnzmMVW9Z9kNI%3
D&amp
;reserved=0
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan-
device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter, so
the zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void
*
filter_param) {
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no
filter then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see
how it develops over time. If we keep these APIs vendor specific for
now we can refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or
the caller.

The concern I have is we don’t know what kinda of ‘filters’ we need
today beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We
will
have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not
periodic, then we have to use if else instead of a simple call with
filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org
<kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle.
I’m
curious if other vendors have channels that have specific features
like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if
(!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F28895&amp;data=04%7C01%7Ccarles.cufi%40nordics
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e
8d%7C
0%7C0%7C637508879620665756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HpXjVqCH
dnoRg
IbGlttgT2pLgUWUr%2Fx3oaLgsR479F4%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major)
and
source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7
C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1
d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTW
Fp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D
&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F2
5e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%
40
n
xp
.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c3
01635
%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
wMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wp3iD
OFIDk
csLjHRqk9OMWe3yiDfBXko6SHkIDrjQeA%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.


Regards,
Hake
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








Hake Huang
 

Hi Gala,

This is a brief introductions for these changes. Hopefully it can help you to explain the context. Please note in Page 8, 9, there are some special data structure changes. Thanks again.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月10日 10:49
To: Kumar Gala <kumar.gala@linaro.org>; Carles Cufi <Carles.Cufi@nordicsemi.no>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Thanks Gala. Really appreciated.

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月9日 21:31
To: Carles Cufi <Carles.Cufi@nordicsemi.no>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

I can present the two options that Hake and I have discussed in this thread to see if there’s any feedback on which direction to take for the new API that is being suggested.

(Happy to do this so Hake doesn’t have to be awake at a crazy hour for him).

- k

On Mar 9, 2021, at 6:17 AM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Hake,

Is this something you want to discuss at the API meeting today? It's at 18h CET.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Hake Huang via lists.zephyrproject.org
Sent: 09 March 2021 12:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I create a new PR
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F33174&amp;data=04%7C01%7Ccarles.cufi%40nordics
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e
8d%7C
0%7C0%7C637508879620655760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xJlwTcev
57aEZ
bDlldIUODWfUpNLzH7SbIUnbTvqMNw%3D&amp;reserved=0 dedicated for the
two new APIS, please check. Thanks in advance.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月5日 11:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
s.hui
hoo.com%2Fdoxygen%2Flinux%2Fkernel%2F3.7%2Fdmatest_8c_source.html&amp
;data
=04%7C01%7Ccarles.cufi%40nordicsemi.no%7C2f7fefddf3df4385a77008d8e2f2
6416%
7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637508879620665756%7CUnk
nown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
XVCI6
Mn0%3D%7C3000&amp;sdata=Sq5QarVur4smW1zz1sWY6nRBMwca2lCnzmMVW9Z9kNI%3
D&amp
;reserved=0
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan-
device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter, so
the zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void
*
filter_param) {
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no
filter then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see
how it develops over time. If we keep these APIs vendor specific for
now we can refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or
the caller.

The concern I have is we don’t know what kinda of ‘filters’ we need
today beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We
will
have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not
periodic, then we have to use if else instead of a simple call with
filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org
<kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle.
I’m
curious if other vendors have channels that have specific features
like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if
(!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F28895&amp;data=04%7C01%7Ccarles.cufi%40nordics
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e
8d%7C
0%7C0%7C637508879620665756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HpXjVqCH
dnoRg
IbGlttgT2pLgUWUr%2Fx3oaLgsR479F4%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major)
and
source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7
C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1
d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTW
Fp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D
&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F2
5e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%
40
n
xp
.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c3
01635
%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
wMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wp3iD
OFIDk
csLjHRqk9OMWe3yiDfBXko6SHkIDrjQeA%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.


Regards,
Hake
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








Hake Huang
 

Hi Gala, Carles,

Is there any feedback on API meeting on this PR?

https://github.com/zephyrproject-rtos/zephyr/pull/33174

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月10日 12:05
To: 'Kumar Gala' <kumar.gala@linaro.org>; 'Carles Cufi' <Carles.Cufi@nordicsemi.no>
Cc: 'devel@lists.zephyrproject.org' <devel@lists.zephyrproject.org>; Maureen Helm <maureen.helm@nxp.com>; 'Erwan Gouriou' <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

This is a brief introductions for these changes. Hopefully it can help you to explain the context. Please note in Page 8, 9, there are some special data structure changes. Thanks again.

Regards,
Hake
-----Original Message-----
From: Hake Huang
Sent: 2021年3月10日 10:49
To: Kumar Gala <kumar.gala@linaro.org>; Carles Cufi <Carles.Cufi@nordicsemi.no>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Thanks Gala. Really appreciated.

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月9日 21:31
To: Carles Cufi <Carles.Cufi@nordicsemi.no>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

I can present the two options that Hake and I have discussed in this thread to see if there’s any feedback on which direction to take for the new API that is being suggested.

(Happy to do this so Hake doesn’t have to be awake at a crazy hour for him).

- k

On Mar 9, 2021, at 6:17 AM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Hake,

Is this something you want to discuss at the API meeting today? It's at 18h CET.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Hake Huang via lists.zephyrproject.org
Sent: 09 March 2021 12:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I create a new PR
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F33174&amp;data=04%7C01%7Ccarles.cufi%40nordics
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e
8d%7C
0%7C0%7C637508879620655760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xJlwTcev
57aEZ
bDlldIUODWfUpNLzH7SbIUnbTvqMNw%3D&amp;reserved=0 dedicated for the
two new APIS, please check. Thanks in advance.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月5日 11:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
s.hui
hoo.com%2Fdoxygen%2Flinux%2Fkernel%2F3.7%2Fdmatest_8c_source.html&amp
;data
=04%7C01%7Ccarles.cufi%40nordicsemi.no%7C2f7fefddf3df4385a77008d8e2f2
6416%
7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637508879620665756%7CUnk
nown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
XVCI6
Mn0%3D%7C3000&amp;sdata=Sq5QarVur4smW1zz1sWY6nRBMwca2lCnzmMVW9Z9kNI%3
D&amp
;reserved=0
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan-
device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter, so
the zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void
*
filter_param) {
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no
filter then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see
how it develops over time. If we keep these APIs vendor specific for
now we can refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or
the caller.

The concern I have is we don’t know what kinda of ‘filters’ we need
today beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We
will
have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not
periodic, then we have to use if else instead of a simple call with
filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org
<kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle.
I’m
curious if other vendors have channels that have specific features
like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if
(!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F28895&amp;data=04%7C01%7Ccarles.cufi%40nordics
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e
8d%7C
0%7C0%7C637508879620665756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HpXjVqCH
dnoRg
IbGlttgT2pLgUWUr%2Fx3oaLgsR479F4%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major)
and
source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7
C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1
d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTW
Fp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D
&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F2
5e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%
40
n
xp
.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c3
01635
%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
wMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wp3iD
OFIDk
csLjHRqk9OMWe3yiDfBXko6SHkIDrjQeA%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.


Regards,
Hake
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








Kumar Gala
 

We didn’t get a chance to discuss in this week’s meeting. Will ask Carles to have it on the agenda for next week.

- k

On Mar 11, 2021, at 10:18 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala, Carles,

Is there any feedback on API meeting on this PR?

https://github.com/zephyrproject-rtos/zephyr/pull/33174

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月10日 12:05
To: 'Kumar Gala' <kumar.gala@linaro.org>; 'Carles Cufi' <Carles.Cufi@nordicsemi.no>
Cc: 'devel@lists.zephyrproject.org' <devel@lists.zephyrproject.org>; Maureen Helm <maureen.helm@nxp.com>; 'Erwan Gouriou' <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

This is a brief introductions for these changes. Hopefully it can help you to explain the context. Please note in Page 8, 9, there are some special data structure changes. Thanks again.

Regards,
Hake
-----Original Message-----
From: Hake Huang
Sent: 2021年3月10日 10:49
To: Kumar Gala <kumar.gala@linaro.org>; Carles Cufi <Carles.Cufi@nordicsemi.no>
Cc: devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Thanks Gala. Really appreciated.

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月9日 21:31
To: Carles Cufi <Carles.Cufi@nordicsemi.no>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

I can present the two options that Hake and I have discussed in this thread to see if there’s any feedback on which direction to take for the new API that is being suggested.

(Happy to do this so Hake doesn’t have to be awake at a crazy hour for him).

- k

On Mar 9, 2021, at 6:17 AM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Hake,

Is this something you want to discuss at the API meeting today? It's at 18h CET.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Hake Huang via lists.zephyrproject.org
Sent: 09 March 2021 12:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I create a new PR
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F33174&amp;data=04%7C01%7Ccarles.cufi%40nordics
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e
8d%7C
0%7C0%7C637508879620655760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xJlwTcev
57aEZ
bDlldIUODWfUpNLzH7SbIUnbTvqMNw%3D&amp;reserved=0 dedicated for the
two new APIS, please check. Thanks in advance.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月5日 11:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
s.hui
hoo.com%2Fdoxygen%2Flinux%2Fkernel%2F3.7%2Fdmatest_8c_source.html&amp
;data
=04%7C01%7Ccarles.cufi%40nordicsemi.no%7C2f7fefddf3df4385a77008d8e2f2
6416%
7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637508879620665756%7CUnk
nown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
XVCI6
Mn0%3D%7C3000&amp;sdata=Sq5QarVur4smW1zz1sWY6nRBMwca2lCnzmMVW9Z9kNI%3
D&amp
;reserved=0
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan-
device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter, so
the zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void
*
filter_param) {
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no
filter then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see
how it develops over time. If we keep these APIs vendor specific for
now we can refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API or
the caller.

The concern I have is we don’t know what kinda of ‘filters’ we need
today beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We
will
have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not
periodic, then we have to use if else instead of a simple call with
filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org
<kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle.
I’m
curious if other vendors have channels that have specific features
like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if
(!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F28895&amp;data=04%7C01%7Ccarles.cufi%40nordics
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5e
8d%7C
0%7C0%7C637508879620665756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HpXjVqCH
dnoRg
IbGlttgT2pLgUWUr%2Fx3oaLgsR479F4%3D&amp;reserved=0
in this PR, I add chain_link by using the dest_chaining_en(Major)
and
source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%7
C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1
d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CTW
Fp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3D
&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F2
5e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang%
40
n
xp
.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c3
01635
%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
wMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wp3iD
OFIDk
csLjHRqk9OMWe3yiDfBXko6SHkIDrjQeA%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.


Regards,
Hake
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








Hake Huang
 

Thanks Gala. Please help to gather feedback.

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月12日 21:29
To: Hake Huang <hake.huang@nxp.com>
Cc: Carles Cufi <Carles.Cufi@nordicsemi.no>; devel@lists.zephyrproject.org; Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

We didn’t get a chance to discuss in this week’s meeting. Will ask Carles to have it on the agenda for next week.

- k

On Mar 11, 2021, at 10:18 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala, Carles,

Is there any feedback on API meeting on this PR?

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F33174&amp;data=04%7C01%7
Chake.huang%40nxp.com%7C4de41a7fc6a447490c8208d8e55acc94%7C686ea1d3bc2
b4c6fa92cd99c5c301635%7C0%7C0%7C637511525449894297%7CUnknown%7CTWFpbGZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C1000&amp;sdata=MhZlkVmynxFHVL3z%2BsS4WBOCz1oJwx2rOm4eTMLQOx8%3D&am
p;reserved=0

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月10日 12:05
To: 'Kumar Gala' <kumar.gala@linaro.org>; 'Carles Cufi'
<Carles.Cufi@nordicsemi.no>
Cc: 'devel@lists.zephyrproject.org' <devel@lists.zephyrproject.org>;
Maureen Helm <maureen.helm@nxp.com>; 'Erwan Gouriou'
<erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

This is a brief introductions for these changes. Hopefully it can help you to explain the context. Please note in Page 8, 9, there are some special data structure changes. Thanks again.

Regards,
Hake
-----Original Message-----
From: Hake Huang
Sent: 2021年3月10日 10:49
To: Kumar Gala <kumar.gala@linaro.org>; Carles Cufi
<Carles.Cufi@nordicsemi.no>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Thanks Gala. Really appreciated.

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月9日 21:31
To: Carles Cufi <Carles.Cufi@nordicsemi.no>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

I can present the two options that Hake and I have discussed in this thread to see if there’s any feedback on which direction to take for the new API that is being suggested.

(Happy to do this so Hake doesn’t have to be awake at a crazy hour for him).

- k

On Mar 9, 2021, at 6:17 AM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Hake,

Is this something you want to discuss at the API meeting today? It's at 18h CET.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Hake Huang via lists.zephyrproject.org
Sent: 09 March 2021 12:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I create a new PR
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
t
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F33174&amp;data=04%7C01%7Ccarles.cufi%40nordic
s
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5
e
8d%7C
0%7C0%7C637508879620655760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
D
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xJlwTce
v
57aEZ
bDlldIUODWfUpNLzH7SbIUnbTvqMNw%3D&amp;reserved=0 dedicated for the
two new APIS, please check. Thanks in advance.

Regards,
Hake

-----Original Message-----
From: Hake Huang
Sent: 2021年3月5日 11:56
To: Kumar Gala <kumar.gala@linaro.org>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: RE: [Zephyr-devel] [EXT] about DMA API updates proposal

Hi Gala,

I try to find some reference from Linux code, and below is my finding.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
c
s.hui
hoo.com%2Fdoxygen%2Flinux%2Fkernel%2F3.7%2Fdmatest_8c_source.html&am
p
;data
=04%7C01%7Ccarles.cufi%40nordicsemi.no%7C2f7fefddf3df4385a77008d8e2f
2
6416%
7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637508879620665756%7CUn
k
nown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
J
XVCI6
Mn0%3D%7C3000&amp;sdata=Sq5QarVur4smW1zz1sWY6nRBMwca2lCnzmMVW9Z9kNI%
3
D&amp
;reserved=0
614 static bool filter(struct dma_chan *chan, void *param)
615 {
616 if (!dmatest_match_channel(chan) || !dmatest_match_device(chan-
device))
617 return false;
618 else
619 return true;
620 }
621
622 static int __init dmatest_init(void)
623 {
624 dma_cap_mask_t mask;
625 struct dma_chan *chan;
626 int err = 0;
627
628 dma_cap_zero(mask);
629 dma_cap_set(DMA_MEMCPY, mask);
630 for (;;) {
631 chan = dma_request_channel(mask, filter, NULL);
632 if (chan) {
633 err = dmatest_add_channel(chan);
634 if (err) {
635 dma_release_channel(chan);
636 break; /* add_channel failed, punt */
637 }
638 } else
639 break; /* no more channels available */
640 if (max_channels && nr_channels >= max_channels)
641 break; /* we have all we need */
642 }
643
644 return err;
645 }

In Linux the dma api use a filter function point as its parameter,
so the zephyr request API can be

static int dma_edma_request_channel(const struct device *dev,
channel_filter_func filter, void
*
filter_param) {
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++) {
if (!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
if (fn && !fn(filter_param)) {
continue;
}
break;
}
}
k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

And each SOC vender response to provide the filter function, if no
filter then just give NULL.


How about this solution?

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月4日 23:00
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>; Erwan Gouriou <erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

1. I think we handle that on a case by case basis and wait and see
how it develops over time. If we keep these APIs vendor specific
for now we can refactor or introduce a general API for ‘filter’ when we see the pattern.

2. The ‘if’ has to exist somewhere. The ‘if’ is either in the API
or the caller.

The concern I have is we don’t know what kinda of ‘filters’ we need
today beyond the ‘periodic’ one which is specific to NXP hardware.

- k

On Mar 3, 2021, at 9:27 PM, Hake Huang <hake.huang@nxp.com> wrote:

Hi Gala,

According to the usage of these two APIs, I have two concerns

1. What if there are other special DMA attribute than periodic? We
will
have to add more APIs?
2. in the peripheral driver, the DMA request can be periodic or not
periodic, then we have to use if else instead of a simple call with
filter.

Regards,
Hake
-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 22:49
To: Kumar Gala <kumar.gala@linaro.org>
Cc: Hake Huang <hake.huang@nxp.com>; devel@lists.zephyrproject.org;
Maureen Helm <maureen.helm@nxp.com>; Erwan Gouriou
<erwan.gouriou@linaro.org>
Subject: Re: [Zephyr-devel] [EXT] about DMA API updates proposal

Caution: EXT Email

Hake,

So I was thinking about the following idea:

Having 2 general purpose APIs:

dma_request_channel(const struct device *dev)
dma_release_channel(const struct device *dev)

Than 2 eDMA specific APIs:

mcux_edma_request_periodic_channel(const struct device *dev)
mcux_edma_release_periodic_channel(const struct device *dev)

- k

On Mar 2, 2021, at 9:28 PM, Kumar Gala via lists.zephyrproject.org
<kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Hake,

The ‘filter’ feature I’m still trying to figure out how we handle.
I’m
curious if other vendors have channels that have specific features
like ‘periodic’ that only are supported on specific channels or not.

Hopefully, Erwan might be able to know for STM32.

- k

On Mar 2, 2021, at 9:06 PM, Hake Huang <hake.huang@nxp.com> wrote:

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) {
break;
}
if
(!atomic_test_and_set_bit(DEV_DATA(dev)->dma_channels,
i)) {
channel = i;
break;
}
}

k_mutex_unlock(&DEV_DATA(dev)->dma_mutex);

return channel;
}

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

Regards,
Hake

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: 2021年3月3日 1:43
To: Hake Huang <hake.huang@nxp.com>
Cc: devel@lists.zephyrproject.org; Maureen Helm
<maureen.helm@nxp.com>
Subject: [EXT] Re: about DMA API updates proposal

Caution: EXT Email

On Feb 26, 2021, at 5:46 AM, Hake Huang <hake.huang@nxp.com> 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.
1.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
t
hub.c
om%2Fzephyrproject-
rtos%2Fzephyr%2Fpull%2F28895&amp;data=04%7C01%7Ccarles.cufi%40nordic
s
emi.n
o%7C2f7fefddf3df4385a77008d8e2f26416%7C28e5afa2bf6f419a8cf6b31c6e9e5
e
8d%7C
0%7C0%7C637508879620665756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
D
AiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HpXjVqC
H
dnoRg
IbGlttgT2pLgUWUr%2Fx3oaLgsR479F4%3D&amp;reserved=0
in this PR, I add chain_link by using the
dest_chaining_en(Major) and
source_chaining_en(minor).
2.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
252
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737&amp;data=04%
7
C0
1
%7
Chake.huang%40nxp.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea
1
d3
b
c2
b4c6fa92cd99c5c301635%7C0%7C0%7C637503037637038943%7CUnknown%7CT
W
Fp
b
GZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
6
Mn
0
%3
D%7C1000&amp;sdata=3QEP18IvoC9MS3C9o274Z0eMIdbIWTzaoZp18la0OzQ%3
D
&a
m
p;
reserved=0 in this PR,
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
252
Fg
i
th
ub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F27737%2Fcommits%2F
2
5e
1
9f
5b4e4ef07b1598104a02c4722386f2f17b&amp;data=04%7C01%7Chake.huang
%
40
n
xp
.com%7C3753d08aba3a4799ddb008d8dda294b0%7C686ea1d3bc2b4c6fa92cd99c5c
3
01635
%7C0%7C0%7C637503037637038943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
A
wMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wp3i
D
OFIDk
csLjHRqk9OMWe3yiDfBXko6SHkIDrjQeA%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.


Regards,
Hake
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