* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
