dai: Add warning about possible glitch

[ktrzcinx]

DMA should be loaded at least with data for one period
otherwise glitches are supposed to appear. Such a kind of
problem is quite difficult to track, because it may be related
with scheduling in runtime, DSP load, or used buffers size,
so log message pointing possible source of glitch is useful.

Signed-off-by: Karol Trzcinski karolx.trzcinski@linux.intel.com

[lgirdwood]

@ktrzcinx just one issue, checkpatch is valid here

#29: FILE: src/audio/dai.c:848:
+	else if (dev->direction == SOF_IPC_STREAM_CAPTURE && copy_bytes + avail_bytes < dd->period_bytes)

[lgirdwood]

I also guess this is no longer an RFC ?

[plbossart]

Not understanding the concept here, sorry

[lgirdwood]

@ktrzcinx do you think you can resolve this today or tomorrow morning ?

[ktrzcinx]

Yes, it looks that I mixed playback with capture, I'm now checking results after swapping

[ktrzcinx]

When I keep original solution (use free+copy_bytes in playback), then results looks good (when output has glitches, then also warning is present in logs), but this solutions looks quite strange, as pointed @plbossart. After changing condition and comparing avail+copy_bytes in playback, then I can't see warning message despite the fact that used math looks better. It looks like there's some issue with avail bytes reads:

[   1055460] (        53) c0 ssp-dai      1.0   ssp_trigger() cmd 1
[   1055466] (         5) c0 ssp-dai      1.0   ssp_start()
[   1055973] (        17) c0 host         1.1   host_copy_normal() 384 bytes
[   1055978] (         6) c0 host               host_dma_cb() 384 bytes
[   1056013] (        12) c0 dai          1.2   dai_copy(): Copy_bytes 0 avail bytes 1264 free bytes 272

In the first copy() iteration it shows here there is 1264 avail bytes in dw-dma but it was first iteration, so dma buffer should be empty. Maybe avail bytes calculation it's a reason of lack warning message in this version.

[lgirdwood]

@ktrzcinx the key for DMA is that the granularity will be period based (since the DMAC will own the period and it's data access are asynchronous to the FW data accesses). We really need the following four checks

1. Playback FW copy() - check is FW writing to DMAC period (beyond DMA HW R ptr)?
2. Playback DMA IRQ - check is DMA now about to start reading from FW period ?
3. Capture FW copy() - check is FW reading from DMAC period (beyond DMA HW W ptr) ?
4. Capture DMA IRQ - check is DMA now about to start writing to FW period ?

[ktrzcinx]

I've prepared better test case, and now it looks to work as expected.

[   1069461] (        14) c0 host         1.1   host_copy_normal()
[   1069469] (         8) c0 host               host_dma_cb() 0xbe04715c
[   1069481] (        12) c0 dai          1.2   dai_copy()
[   1069488] (         7) c0 dai          1.2   dai_copy(), dir: 0 copy_bytes= 0x200, avail 192  free 1344
[   1069493] (         5) c0 dai          1.2   dai_dma_cb()
[   1070403] (       910) c1 codec_adapter 1.0   codec_adapter_copy() start lib_buff_size: 512, bytes_to_process: 640, MIN(sink 768, source 640)
[   1070409] (         6) c1 codec_adapter 1.0   source inter_core: 1 sink inter_core: 1 (buff 4b3b==4b3b)
[   1070414] (         3) c1 codec_adapter 1.0   codec_process() start
[   1070418] (         4) c1 codec_adapter 1.0   cadence_codec_process() start
[   1070461] (        15) c0 host         1.1   host_copy_normal()
[   1070469] (         8) c0 host               host_dma_cb() 0xbe04715c
[   1070481] (        12) c0 dai          1.2   dai_copy()
[   1070488] (         7) c0 dai          1.2   dai_copy(), dir: 0 copy_bytes= 0x0, avail 320  free 1216
[   1070492] (         4) c0 dai          1.2   WARN dai_copy(): Copy_bytes 0 + avail bytes 320 < period bytes 384
[   1070647] (       155) c1 codec_adapter 1.0   cadence_codec_process() done, #1 avail 512 produced 512 cpd 0xbe092140
[   1070652] (         5) c1 codec_adapter 1.0   codec_process() end

Output looks like this:

And here's the theory behind this situation:

Issue with initial avail bytes size is still visible and needs futher investigation.
edit: It's zero-filled buffers content from the initial stage.

[lgirdwood]

SOFCI TEST