* Peter Ujfalusi peter.ujfalusi@ti.com [160905 00:53]:
On 09/02/16 23:40, Tony Lindgren wrote:
Hmm well actually with the fifo threshold your calculations above start making some sense. The missing piece is that we will never hit off mode until DMA is done. So the true worst case would be:
- 2.9 - 13.06 ms for the fifo threshold minus dma setup time
- plus the time it takes to complete the fifo fill with dma as dma will keep the SoC active
- plus the time it takes to idle the dma after the last fifo fill as the dma will keep SoC active
Yeah, I have done this calculations for the DADC33 mode7LP mode :D
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.
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