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

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi at ti.com> [160913 04:45]:
> On 09/10/16 02:45, Tony Lindgren wrote:
> >> In any way, according to the numbers:
> >> C7 is (7505 + 15274) vs (10000 + 30000)
> >> C6 is (7580 + 4134) vs (3000 + 8500)
> >> C5 is (855 + 1146) vs (2500 + 7500)
> >> C4 is (121 + 3374) vs (1500 + 1800)
> >> C3 is (107 + 410) vs (50 + 50)
> >>
> >> with the 30ms QoS we set we will still hit OFF on OMAP3430, it should minimum
> >> 11.715ms for omap3430, but that will block C6 on omap36xx.
> > 
> > Yeah those don't seem to be correct. The Nokia N9(50) kernel seems to have
> > some measured numbers for 36xx.
> 
> True, probably we should give those numbers a try? It looks like they have
> C1...C8 compared to mainline which have C1...C7.

Well some of those numbers are based on OSWR (Open SWitch Retention), not
sure if that works properly with mainline. Worth trying though.

> >> If we could have the data for the struct cpuidle_state coming from DT and not
> >> wired in the cpuidle34xx/44xx files then the McBSP driver could look up the C7
> >> number and block that...
> > 
> > I'm now thinking that your fifo threshold calculation is what we should
> > do, then fix the cpuidle latencies and playback should hit retention idle.
> 
> Right. So the QoS should be set time(FIFOsize - FIFOthreshold) - margin?
> What margin we should use? The DMA does not need setup time as it will just
> continue where it stopped, so probably we can ignore the margin and use the
> number we got from the FIFO use?

Yeah seems safe assuming the mystery numbers are wrong C state latencies :)

> During hw_param we can calculate this, but we need to consider on more thing:
> we need to make sure that the QoS we place covers the capture and the playback
> as well, so we need to use the worst case number. the FIFO threshold can be
> different for capture and playback.

OK makes sense to me.

Regards,

Tony