hda: hw support for hda chain

[makarukp]

This PR enables hardware support for HDA chain transfers (without deploying internal pipelines):
Content:

• hda chain management
• hda chain tasks and DMA logic implementation

Signed-off-by: Piotr Makaruk piotr.makaruk@intel.com

[lgirdwood]

@makarukp is this PR still pending validation or implementation completion or external dependencies ?

[makarukp]

@lgirdwood This PR is still under development, it requires at lease one more commit with code completion before it is ready for validation.

[makarukp]

Code is completed. PR is ready for validation.

[lyakh]

yeah, this looks a bit suspicious. And in fact dw_dma_get_status() can return -EINVAL if the channel number is invalid, and that is a hard error and in that case stat isn't filled. So, this at least deserves a comment, much more so than the two comments above which explain something, that's pretty clear from the code itself.

[makarukp]

@lyakh What do you think about such approach of critical error handling in response to 'dma_get_status()' ?

/* Status can return -ENODATA and current status if xrun occurs, then it is not critical
* and flow shall continue. In worst case, when channel index exceeds max value, status can
* return -EINVAL, then it is critical error.
*/
ret = dma_get_status(cd->chan_link->dma->z_dev, cd->chan_link->index, &stat);
switch (ret) {
case 0:
break;
case -ENODATA:
tr_warn(&chain_dma_tr, "chain_task_run(): dma_get_status() xrun occured, ret = %u",
ret);
break;
default:
tr_err(&chain_dma_tr, "chain_task_run(): dma_get_status() error, ret = %u", ret);
return SOF_TASK_STATE_COMPLETED;
}

[lyakh]

Status can return -ENODATA and current status if xrun occurs

According to https://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html-EPIPE is used by ALSA to indicate an xrun?

[makarukp]

@lyakh Accually -EINVAL can be returned in current implementation only by dw_dma_get_status() which is used by GPDMA in Zephyr. DMA uses intel_adsp_hda_dma_status() and there is only assertion __ASSERT(channel < cfg->dma_channels, "Channel does not exist"); .

[kv2019i]

This starts to look good. A few minor issues, but no showstoppers.

[lyakh]

ipc4_chain_manager_create() seems to be a better name for this, but it's already there

[lgirdwood]

@lyakh this looks resolved now, error code is checked ?

[lgirdwood]

@ujfalusi resolved ?

[marc-hb]

This apparently caused regressions #6975 and #6976.

It was also merged while failing a large number of tests: https://sof-ci.01.org/sofpr/PR6656/build3409/devicetest/index.html

[lgirdwood]

There is a lot of test failures on ADL capture, I've created a revert PR that can be merged today prior to daily test runs if we don't have fixes ready in time.

[lgirdwood]

@makarukp@mwasko@kv2019i@lyakh fyi - does anyone have fix PRs in progress otherwise we will have to revert ?

[mwasko]

@makarukp@mwasko@kv2019i@lyakh fyi - does anyone have fix PRs in progress otherwise we will have to revert ?

@lgirdwood, @kv2019i the regression is affecting only cAVS targets which are not POR in Zephyr configuration. The tests were passing before on cAVS because they were using w/a in form of copier-copier solution which is not correct implementation. We should treat it as we have enabled feature for MTL and for cAVS it is a to do action (on best effort basis).

[lgirdwood]

@makarukp@mwasko@kv2019i@lyakh fyi - does anyone have fix PRs in progress otherwise we will have to revert ?

@lgirdwood, @kv2019i the regression is affecting only cAVS targets which are not POR in Zephyr configuration. The tests were passing before on cAVS because they were using w/a in form of copier-copier solution which is not correct implementation. We should treat it as we have enabled feature for MTL and for cAVS it is a to do action (on best effort basis).

I'm fine to make this a MTL only feature, but it should not break legacy features on other platforms. Can this be fixed with a Kconfig ?

[makarukp]

@makarukp@mwasko@kv2019i@lyakh fyi - does anyone have fix PRs in progress otherwise we will have to revert ?

@lgirdwood, @kv2019i the regression is affecting only cAVS targets which are not POR in Zephyr configuration. The tests were passing before on cAVS because they were using w/a in form of copier-copier solution which is not correct implementation. We should treat it as we have enabled feature for MTL and for cAVS it is a to do action (on best effort basis).

I'm fine to make this a MTL only feature, but it should not break legacy features on other platforms. Can this be fixed with a Kconfig ?

@lgirdwood Unfortunately it is not possible to fix it with Kconfig because legacy approach was erased by hw chain dma PR.

As for #6975 (comment) issue it does not look like a big deal. I will prepare debug FW which could probably solve that problem or provide at least more information.

As for #6976 (comment) issue I don't know what happened and still thinking about further steps for debug ...

[makarukp]

I prepared fix for #6975:
#6983