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

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

On 09/02/2016 06:54 PM, Pavel Machek wrote:
> Hi!
> 
>>>> 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.
>>
>> I wonder why we have not seen this before? I can not recall anything like this
>> with n900 (Jarkko might know that better) neither with n9/n950. On the n9/n950
>> I have even put the OMAP3 to OFF during audio playback with the
> 
> I was seeing something like that with 4.x kernel on Nokia N900.

So it must be possible to reproduce it on BeagleBoard-xm... I will try to get
the PM working on it and let's see (hear).


-- 
Péter