[alsa-devel] [PATCH] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi at ti.com> [160831 23:58]:
> What is the audio format you are using? sampling rate and how many channels?
> cat /proc/asound/card0/pcm0p/sub0/hw_params

Just 44.1 stereo mp3 or wav files.

> What happens if you set the FIFO to 256? Do you still need the 30ms or it can
> be higher, like 60ms?

No this is not related to the FIFO size. We just need to block off idle mode
for cpuidle as the McBSP hardware is not blocking it.

> When the FIFO is set to 128, it means that after the initial FIFO fill we will
> have DMA request coming from McBSP to sDMA with a rate of:
> 
> (1000/sampling_rate) * (FIFO-threshold / channels) = DMA_req_distance_in_ms
> 
> So in case of 44.1KHz, stereo with 128 FIFO threshold DMA request will come at
> every 1.45ms. If I'm not mistaken. The whole FIFO (1280) holds 14.51ms of
> audio in this case.
> 
> I don't see this correlate with the 30ms at all.

It seems we easily have a situation where DMA is done buffering to McBSP,
and PMIC is playing audio, and we hit idle. At that point there are no immediate
timers pending and cpuidle determines we can try to hit a deeper idle mode. As
there are no hardware blockers with DMA off and McBSP not blocking, the hardware
hits off mode. This cuts power to McBSP.

Ideally we'd configure McBSP activity to block deeper idle states in the
hardware but I don't think we have such a configuration available.

So we just want to tell pm_qos that McBSP can't take any idle states shorter
than 30 ms to prevent cutting off power fro the whole SoC.

> Do you see anything in the kernel log? If McBSP is not powered and DMA tries
> to write data we should see l3 error at least. If the reason is that the
> system is not able to wake up fast enough to react to the DMA request from
> McBSP, then we should see FIFO underrun from McBSP (this patch will show them:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/111671.html)

No, nothing as both McBSP and DMA are powered off :) Coming back from
idle, from McBSP and DMA point of view things appear as if nothing happened.
I think we're still missing the save and restore of the McBSP state, but
that's a different story and does not help with the fact that we allow
cutting off the power to McBSP during playback.

With Linux next with the patch above, I do see occasional interrupts
for "omap-mcbsp 49022000.mcbsp: TX Buffer Overflow!" but those seem
to also happen if I keep the system busy and I don't hear any dropped
samples.

> Have you tried with different sampling rates? That would have similar effect
> as changing the FIFO threshold for the DMA request periods.

Not very much, but this seems more like a SoC specific issue.

Regards,

Tony