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

[Peter Ujfalusi]

On 09/06/2016 11:16 PM, Tony Lindgren wrote:
>> While the calculation is correct for the wake latency requirements, there is a
>> flip side:
>> FIFO threshold 128:
>> - wake threshold is ~13.06ms to ensure that we don't drain the FIFO
>> - DMA requests are coming at 1.45ms rate.
>>
>> While we could take a C state which would take ~13.06ms to leave, in reality
>> the system will be busy to respond to the DMA request coming in every 1.45ms.
>>
>> FIFO threshold is 1024:
>> - wake threshold is ~2.9ms to ensure that we don't drain the FIFO
>> - DMA requests are coming at 11.6ms rate.
>>
>> In this case we only going to allow C state from which we can leave under
>> 2.9ms, but between DMA burst we have 11.6ms. We could be in deeper state, but
>> we are going to be woken up by the DMA request and after the DMA request we
>> have ~2.9ms before the FIFO is empty...
>>
>> So either we allow deeper C state (threshold 128) which we might not able to
>> take to the 'fast' DMA requests, or we only allow shallow C state (threshold
>> 1024), and have more time between the DMA requests.
>>
>> Is this makes sense?
> 
> Makes sense. Do you have a formula or updated patch I can test here?
> Then we can add comments about the possible unaccounted latencies that
> can be worked out as needed.

Not yet, but I'll try to come up with something in the coming days.

btw: I have tried the idle off on beagbeboard-xm with audio, but even w/o the
qos it is not triggering. w/o audio I hit off but if audio is running, not.

btw2: if you set the qos to 30ms and set the mcbsp2 threshold to 1024 (or
leave it as default) do you have audio glitches? I think if we hit C6 we
should not be able to wake up in time...

>>> The dma setup, complete, and idle latencies here can be probably
>>> be measured with hrtimer :) That still does not explain we don't
>>> miss anything in retention idle currently.
>>>
>>>> I don't know the PM code that well, but is there a way to set attribute to a
>>>> device to tell how deep C state it can tolerate on the given board or SoC?
>>>
>>> I believe we can only set the pm_qos latency requirements and there
>>> is no direct limiting of C states. Then I think the idea of
>>> dev_pm_qos and set_latency_tolerance callback is that it allows the
>>> SoC specific code to select the allowed C states. So if we
>>> implemented set_latency_tolerance in the cpuidle driver, we could
>>> tinker directly with the C states for latencies.
>>
>> What we can agree on is that OFF need to be blocked when audio is in use. But
>> I'm not sure what is the correct way.
> 
> AFAIK pm_qos is the only Linux generic way to block certain C states.
> 
> Regards,
> 
> Tony
> 


-- 
Péter