dma: switch to native Zephyr API for dw-dma & HDA #5610

abonislawski · 2022-03-28T14:20:48Z

This patch will add dw-dma wrapper for zephyr driver

Opens:

sof dma ops names: dma_channel_put_sof? dw_dma_channel_put_zephyr?
zephyr/CMakeLists.txt: dma-zephyr.c should be restricted for a specific platform/s?

teburd · 2022-03-31T15:22:05Z

This seems like a nice way to adapt the SOF <-> Zephyr APIs

src/audio/dai.c

src/platform/intel/cavs/lib/dma.c

src/drivers/dw/dma-zephyr.c

lyakh · 2022-04-04T13:33:30Z

src/drivers/dw/dma-zephyr.c

this doesn't look right - dma_block_cfg has been incremented block_count times in the loop above. Also, I don't think that parameter is "consumed" by dma_config() so we have to free it in the success case too.

src/drivers/dw/dma-zephyr.c

lgirdwood

Needs to be more generic and not per DMA driver.

src/audio/dai.c

sys-pt1s · 2022-04-15T11:34:53Z

Can one of the admins verify this patch?

lgirdwood · 2022-04-25T17:40:16Z

@abonislawski any update ?
My expectation is that for each DMA API call we have today we would map current users onto the Zephyr version of that call and wrap the SOF version (for existing xtos users).
e.g. for dma_stop()

 grep -rn " dma_stop(" --include=*.c
src/trace/dma-trace.c:375:		err = dma_stop(d->dc.chan);
src/audio/host.c:604:		ret = dma_stop(hd->chan);
src/audio/dai.c:782:		ret = dma_stop(dd->chan);
src/audio/dai.c:786:		ret = dma_stop(dd->chan);
src/probe/probe.c:175:	err = dma_stop(dma->dc.chan);
src/probe/probe.c:177:		tr_err(&pr_tr, "probe_dma_deinit(): dma_stop() failed");

These would be mapped to the native Zephyr API call i.e. all user would be converted to use

int dma_stop(const struct device *dev, uint32_t channel)¶

We would need to convert the existing SOF dma calls to the Zephyr APIs as the first part of this work and then add in support for linking with the Zephyr implementation of this API.

@juimonen same applies to SSP and other DAI drivers.

abonislawski · 2022-05-03T07:42:27Z

@lgirdwood this approach will require to switch all dma or all dai drivers once. With sof api -> zephyr api wrapper we can merge and test each driver separately, it is also possible to use for example one dai driver from sof and one from zephyr.
Can we go this way until all drivers are ready and then in separate final step switch dma/dai api to native zephyr?

lgirdwood · 2022-05-03T15:46:40Z

@lgirdwood this approach will require to switch all dma or all dai drivers once. With sof api -> zephyr api wrapper we can merge and test each driver separately, it is also possible to use for example one dai driver from sof and one from zephyr. Can we go this way until all drivers are ready and then in separate final step switch dma/dai api to native zephyr?

I want to avoid having an intermediate stage to develop and validate, I think it's fine to transition in steps with a Kconfig option "Use Zephyr drivers" with default value n. This means that all the local xtos based driver will be used unless this Kconfig is "y".
i.e. stages with Zephyr drivers enabled.

HDA DMA and HDA/HDMI audio - only HDA and trace can be tested.
DW DMA and DMIC, SSP - DMIC and SSP can also be tested.
Remaining Intel DAIs - all features now enabled.

abonislawski

@lgirdwood please take a look, added early version but few things still needs to be changed

added host_zephyr.c and dai_zephyr.c, so both HDA and DW-DMA (similar changes)
sof dma lib not divided yet

Please ignore _sof functions, it will be reverted later

abonislawski · 2022-05-12T07:20:12Z

src/audio/host_zephyr.c

The main issue is dma_config, Im still using old config and translating it to the dma_config at the end, which is obviously wrong but the old config contain some fields which are not available in the new config, like is_scheduling_source, not sure if we can ignore such fields?

abonislawski · 2022-05-12T07:23:07Z

src/audio/host_zephyr.c

dma_get_attrubite is still missing in new version, Zephyr API does not support this.
Not sure if we can use here defines directly?

lgirdwood · 2022-05-24T12:27:00Z

Both this and #5731 are/were abstracting at the wrong point. The abstraction points for DMA are src/audio/dai.c and src/audio/host.c. This needs to be mechanically changed to

create a dai-zephyr.c (starts to use native Zephyr APIs) and copy dai.c to dai-legacy.c (this last file is exact copy of dai.c today plus any legacy dai logic from lib/dai.c).

same as 1) for host.c
Good for call if needed.

One more thing, lets not use _sof suffixes for the legacy APIs. We can use _legacy instead and this would also align with the file name.

dbaluta · 2022-05-25T06:10:42Z

@abonislawski , maybe this could be useful.

FYI: zephyrproject-rtos/zephyr@2035f3a

abonislawski · 2022-05-25T08:53:59Z

Both this and #5731 are/were abstracting at the wrong point. The abstraction points for DMA are src/audio/dai.c and src/audio/host.c. This needs to be mechanically changed to

create a dai-zephyr.c (starts to use native Zephyr APIs) and copy dai.c to dai-legacy.c (this last file is exact copy of dai.c today plus any legacy dai logic from lib/dai.c).

same as 1) for host.c
Good for call if needed.

@lgirdwood please check carefully, this is how it works now with native zephyr api in src/audio/dai_zephyr.c and src/audio/host_zephyr.c, I can also rename them to dai.c/host.c and old version to dai-legacy.c/host-legacy.c

lgirdwood · 2022-05-25T09:32:43Z

@lgirdwood please check carefully, this is how it works now with native zephyr api in src/audio/dai_zephyr.c and src/audio/host_zephyr.c, I can also rename them to dai.c/host.c and old version to dai-legacy.c/host-legacy.c

Yes please - we really need to make it obvious what files are Zephyr and what files are legacy. Also please use the _legacy suffix. This gives us a clear dividing line.

abonislawski · 2022-05-26T19:07:35Z

@lgirdwood updated with new legacy/zephyr suffix, also added CONFIG_ZEPHYR_NATIVE_DRIVERS as you adviced previously so we can enable it later when everything is ready along with dai PR
hopefully fixed all checkpatch issues etc

lgirdwood

This is a good first step toward full native Zephyr. Next things (in subsequent PRs) are

Reduce other SOF native RTOS APIs in host-zephyr.c and dai-zephyr.c and use the Zephyr versions, i.e for PM, notifiers memory.
Fix the DAI, DMA init to have const tables of DT name strings and topology IDs so that teh CC does more of the init and not the runtime code.

lgirdwood · 2022-05-30T08:46:56Z

SOFCI TEST

lyakh · 2022-05-30T07:51:21Z

src/audio/CMakeLists.txt

I think it should be possible to split this patch, making the renaming to *legacy file and function names a separate patch?

src/audio/dai-zephyr.c

src/audio/host-zephyr.c

abonislawski · 2022-05-31T08:18:41Z

@lyakh I will fix most of your comments today but please note that this PR is not about dai&host refactor

This patch will add new versions of host and dai components with Zephyr native DMA support Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>

Get device binding for DW-DMA & HDA drivers using Zephyr API Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>

abonislawski requested review from akloniex, bardliao, dbaluta, lbetlej, lgirdwood, lyakh, marcinszkudlinski, mmaka1 and plbossart as code owners March 28, 2022 14:20

abonislawski force-pushed the zephyr_dma branch 2 times, most recently from 7906394 to 2bd603a Compare March 28, 2022 14:46

lyakh requested changes Apr 4, 2022

View reviewed changes

lgirdwood requested changes Apr 4, 2022

View reviewed changes

src/audio/dai.c Outdated Show resolved Hide resolved

abonislawski force-pushed the zephyr_dma branch from 2bd603a to f96522f Compare May 12, 2022 07:03

abonislawski requested review from aborisovich, libinyang and marc-hb as code owners May 12, 2022 07:03

abonislawski force-pushed the zephyr_dma branch 2 times, most recently from 16a8782 to 0dd3035 Compare May 12, 2022 07:12

abonislawski commented May 12, 2022

View reviewed changes

abonislawski changed the title ~~dma: cavs: switch to Zephyr driver for dw-dma~~ [RFC] dma: switch to native Zephyr API for dw-dma & HDA May 12, 2022

abonislawski requested review from lgirdwood and lyakh May 24, 2022 07:23

abonislawski changed the title ~~[RFC] dma: switch to native Zephyr API for dw-dma & HDA~~ dma: switch to native Zephyr API for dw-dma & HDA May 24, 2022

lgirdwood added the P1 Blocker bugs or important features label May 24, 2022

abonislawski force-pushed the zephyr_dma branch from 0dd3035 to b35c251 Compare May 26, 2022 17:55

abonislawski requested review from a team, RanderWang, mrajwa and singalsu as code owners May 26, 2022 17:55

abonislawski force-pushed the zephyr_dma branch 5 times, most recently from 8b35ad7 to a7089d0 Compare May 26, 2022 19:00

abonislawski requested review from kv2019i and lgirdwood and removed request for a team and lgirdwood May 26, 2022 19:16

lgirdwood approved these changes May 27, 2022

View reviewed changes

lyakh reviewed May 30, 2022

View reviewed changes

abonislawski force-pushed the zephyr_dma branch 2 times, most recently from f48e9e3 to a54a272 Compare May 31, 2022 11:03

abonislawski added 2 commits May 31, 2022 13:03

dma: add Zephyr native DMA support to host & dai

cf4e9e0

This patch will add new versions of host and dai components with Zephyr native DMA support Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>

dma: cavs: use Zephyr DW-DMA & HDA drivers

a54a272

Get device binding for DW-DMA & HDA drivers using Zephyr API Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>

lgirdwood approved these changes May 31, 2022

View reviewed changes

lgirdwood merged commit a145313 into thesofproject:main May 31, 2022

kv2019i mentioned this pull request Jun 8, 2022

[FEATURE][meta] Use Zephyr native interfaces #5794

Open

26 tasks

dma: switch to native Zephyr API for dw-dma & HDA #5610

dma: switch to native Zephyr API for dw-dma & HDA #5610

Uh oh!

Conversation

abonislawski commented Mar 28, 2022

Uh oh!

teburd commented Mar 31, 2022

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lyakh Apr 4, 2022

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sys-pt1s commented Apr 15, 2022

Uh oh!

lgirdwood commented Apr 25, 2022

Uh oh!

abonislawski commented May 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lgirdwood commented May 3, 2022

Uh oh!

abonislawski left a comment

Choose a reason for hiding this comment

Uh oh!

abonislawski May 12, 2022

Choose a reason for hiding this comment

Uh oh!

abonislawski May 12, 2022

Choose a reason for hiding this comment

Uh oh!

lgirdwood commented May 24, 2022

Uh oh!

dbaluta commented May 25, 2022

Uh oh!

abonislawski commented May 25, 2022

Uh oh!

lgirdwood commented May 25, 2022

Uh oh!

abonislawski commented May 26, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lgirdwood left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lgirdwood commented May 30, 2022

Uh oh!

lyakh May 30, 2022

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

abonislawski commented May 31, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

abonislawski commented May 3, 2022 •

edited

Loading

abonislawski commented May 26, 2022 •

edited

Loading

lgirdwood left a comment •

edited

Loading