Host component DMA copy the whole copy_bytes.

[fuyuntsuo]

Host component stops copying bytes at element's end and resumes
copying the remaining bytes in the next round. This leads to jitter
between components of the same pipeline. Such jitter might cause
buffer overwrite for component which processes block by block.

Triggering extra DMA copy until all the copy_bytes are copied can
eliminate the jitter and hence no more buffer overwrite occurs.

Signed-off-by: fy.tsuo fy.tsuo@intelli-go.com

[fuyuntsuo]

This is a fix for CONFIG_HOST_PTABLE.

It is helpful if anyone can explain this config because I couldn't find any information about it.

[keyonjie]

@fuyuntsuo what platform are you working on? this is not enable on Intel's cAVS platforms, please see it in src/platform/Kconfig.
And, your changes breaks Intel's non-cAVS platforms (BDW, BYT) thoroughly according to the CI on device test result.

[keyonjie]

The change breaks Intel's non-cAVS platforms.

[fuyuntsuo]

It's MT8195 DUT we use to verify the change. We know there are many platforms selecting CONFIG_HOST_PTABLE but MT8915 is the only one we have.

The change is component-level so theoretically it should be platform-independent. If possible @keyonjie can you share what error Intel non-cAVS platforms show? Then we can find out what this change is missing. Thanks!

[keyonjie]

It's MT8195 DUT we use to verify the change. We know there are many platforms selecting CONFIG_HOST_PTABLE but MT8915 is the only one we have.

The change is component-level so theoretically it should be platform-independent. If possible @keyonjie can you share what error Intel non-cAVS platforms show? Then we can find out what this change is missing. Thanks!

you can just click "Details" of "sof-ci/jenkins/pr-device-test" to see the on device test result, or here is the link:
https://sof-ci.01.org/sofpr/PR5001/build11164/devicetest/

[keyonjie]

@fuyuntsuo some logs quoted from the etrace:

[   364066419.127050] (      277631.093750) c0 dma-trace              src/drivers/dw/dma.c:284  ERROR dw_dma_start(): dma 1 channel 1 not ready ena 0x6 status 0x3
[   364066548.502045] (         129.375000) c0 dma-trace                  src/audio/host.c:153  ERROR host_dma_set_config_and_copy(): dma_copy() failed, ret = -16
[   364066691.366623] (         142.864578) c0 dma-trace          ....../pipeline-stream.c:134  ERROR pipeline_copy(): ret = -16, start->comp.id = 9, dir = 1
[   364066816.679118] (         125.312492) c0 dma-trace          ..../pipeline-schedule.c:160  ERROR pipeline_task(): xrun recovery failed! pipeline is stopped.

[fuyuntsuo]

@keyonjie Thanks for the hint! Seems like this DMA call sequence does not apply to all the platforms selecting CONFIG_HOST_PTABLE.

Unfortunately we have only MT8195 to verify this PR. Can anyone advise how to avoid breaking Intel's non-cAVS platfroms?

[lgirdwood]

I think this fix to force DMA to copy the block size is a needed feature, but we probably want to have this a Kconfig option where it's default can be set y or n depending on the platform.

[keyonjie]

SOFCI TEST

[fuyuntsuo]

SOFCI TEST

Thanks @keyonjie. Will manually trigger CI with this command by myself next time.

The PR doesn't break Intel non-cAVS platforms anymore (thanks @lyakh!). I will add a Kconfig later.

[lgirdwood]

Lets take this for v2.0 with the Kconfig update.

[fuyuntsuo]

Just wondering: does this needs DMA_COPY_BLOCKING flag too?

[lgirdwood]

it should block the caller until DMA copy completes.

[lgirdwood]

@yaochunhung @kuanhsuncheng good for you ?

[lgirdwood]

CI failures unrelated and known.