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