[0/9] ASoC: SOF: core/ipc4/mtl: Add support for PCM delay reporting

Hi,

The following series adds support for the PCM delay reporting in SOF core level
and implements the needed infrastructure with IPC4 to finally enable it for MTL.

Currently this is only supported on MTL (and via IPC4), but with the
infrastructure in place it will be possible to support other platforms with
DeepBuffer.

Regards,
Peter
---
Rander Wang (9):
  ASoC: SOF: add ipc4_fw_reg header file
  ASoC: SOF: add fw_info_box support
  ASoC: SOF: add time info structure for ipc4 path
  ASoC: SOF: ipc4-pcm: allocate time info for pcm delay feature
  ASoC: SOF: ipc4-pcm: add hw_params
  ASoC: SOF: add delay function support in sof framework
  ASoC: SOF: add get_stream_position ops for pcm delay
  ASoC: SOF: Intel: mtl: add get_stream_position support
  ASoC: SOF: ipc4-pcm: add delay function support

 sound/soc/sof/intel/mtl.c   |  14 +++
 sound/soc/sof/intel/mtl.h   |   6 +
 sound/soc/sof/ipc4-fw-reg.h | 155 ++++++++++++++++++++++++
 sound/soc/sof/ipc4-pcm.c    | 230 ++++++++++++++++++++++++++++++++++++
 sound/soc/sof/ipc4-priv.h   |  15 +++
 sound/soc/sof/ipc4.c        |   3 +
 sound/soc/sof/ops.h         |  10 ++
 sound/soc/sof/pcm.c         |  13 ++
 sound/soc/sof/sof-audio.h   |   6 +
 sound/soc/sof/sof-priv.h    |  10 ++
 10 files changed, 462 insertions(+)
 create mode 100644 sound/soc/sof/ipc4-fw-reg.h

On 01/02/2023 14:44, Jaroslav Kysela wrote:
> On 01. 02. 23 13:32, Peter Ujfalusi wrote:
> 
>> +static snd_pcm_sframes_t sof_ipc4_pcm_delay(struct snd_soc_component
>> *component,
>> +                        struct snd_pcm_substream *substream)
>> +{
> 
> ...
> 
>> +
>> +    /*
>> +     * Handle 32-bit counter wrap around, which would happen
>> +     * for a 48khz 2ch stream in 24.855 hours
>> +     */
>> +    link_ptr = tmp_ptr & UINT_MAX;
>> +
>> +    host_ptr = substream->runtime->status->hw_ptr;
>> +
>> +    if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
>> +        return host_ptr - link_ptr;
>> +
>> +    return link_ptr - host_ptr;
> 
> I don't think that this calculation is fine for the wrap point. The
> hw_ptr is in range 0..pcm_boundary not UINT_MAX.

That is true. Our link counter is u64 (and it is counting the bytes, not
a real DMA position) so I can
tmp_ptr %= substream->runtime->boundary;

then handle the wrap of both later.

> Also, you should consider the underrun/overrun situations.

>The simple substraction is not enough to handle this correctly.

Yes, you are right. I will send v2 right away(ish)

Thanks,
Péter

On Wed, 01 Feb 2023 14:32:22 +0200, Peter Ujfalusi wrote:
> The following series adds support for the PCM delay reporting in SOF core level
> and implements the needed infrastructure with IPC4 to finally enable it for MTL.
> 
> Currently this is only supported on MTL (and via IPC4), but with the
> infrastructure in place it will be possible to support other platforms with
> DeepBuffer.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/9] ASoC: SOF: add ipc4_fw_reg header file
      commit: 2740dcce918f385aea0fb0a026cc0b91629479af
[2/9] ASoC: SOF: add fw_info_box support
      commit: 4700bfb2bb3acae63ff4cbf82fbde35a325ebdf2
[3/9] ASoC: SOF: add time info structure for ipc4 path
      commit: 65a8ef494aff8bceac9a952ae8f6a1681231aee5
[4/9] ASoC: SOF: ipc4-pcm: allocate time info for pcm delay feature
      commit: af74dbd0dbcf49e8a3ae3e766683e13ecaf71e3b
[5/9] ASoC: SOF: ipc4-pcm: add hw_params
      commit: 7cb19007baba0c7a76bd3f8f324a6b6548025968
[6/9] ASoC: SOF: add delay function support in sof framework
      commit: 27c2100b6bc8b0b064f89250eb4081431299115f
[7/9] ASoC: SOF: add get_stream_position ops for pcm delay
      commit: 7f956297272bbc3535a02fa32579375a0d40283c
[8/9] ASoC: SOF: Intel: mtl: add get_stream_position support
      commit: faceb3445aaf1704583744b48c622dbc96ef9ab2
[9/9] ASoC: SOF: ipc4-pcm: add delay function support
      commit: 3937a76c64931109dfafa999a0c78b4df2a6e0a1

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark