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

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi at 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