ASoC: SOF: ipc4-pcm: Delay reporting is only supported for playback d…

[ujfalusi]

…irection

The firmware does not provide any information for capture streams via the shared pipeline registers.

To avoid reporting invalid delay value for capture streams to user space we need to disable it.

Fixes: af74dbd ("ASoC: SOF: ipc4-pcm: allocate time info for pcm delay feature")
Cc: [email protected]

[lgirdwood]

@ujfalusi are you saying we are missing information about capture streams ? is this a FW bug ? @kv2019i

[ujfalusi]

@ujfalusi are you saying we are missing information about capture streams ? is this a FW bug ? @kv2019i

I think it is by design in firmware that no pipeline information is kept for capture streams:
https://github.com/thesofproject/sof/blob/c1df459ca914c89d3cd51bac44a9e683d8eba395/src/audio/copier/copier.c#L327

Somehow the number of fw registers section depends on the number of playback channels:
https://github.com/thesofproject/sof/blob/c1df459ca914c89d3cd51bac44a9e683d8eba395/src/audio/copier/copier_host.c#L108-L111

The pipeline regs are only initialized in case of playback, that's why pipeline_reg_offset remains 0 for capture streams:
https://github.com/thesofproject/sof/blob/c1df459ca914c89d3cd51bac44a9e683d8eba395/src/audio/copier/copier_host.c#L212

It looks to be by design.

[ujfalusi]

I can fix this in kernel...

[ujfalusi]

I could handle this in kernel, but it is only going to work for HD-DMA on link side and even with that it is not going to work in case of a split topology path (one DAI to multiple PCMs). It is better and safer to not report the delay in capture at all.