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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
