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

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi at ti.com> [160908 23:52]:
> On 09/08/16 17:48, Tony Lindgren wrote:
> >>> My findings so far:
> >>> w/o the QoS patch we will hit core OFF even if we are in element mode in McBSP:
> >>> # cat /sys/devices/platform/68000000.ocp/49022000.mcbsp/dma_op_mode
> >>> [element] threshold
> >>>
> >>> If I start the playback we will hit core OFF even if the we have DMA request
> >>> coming at every sample (every 0.02ms).
> > 
> > I think that's because we still have windows without pm qos where dma
> > is not active and we hit idle and there's nothing in hardware blocking
> > off mode.
> 
> Hrm. Should we block idle when the FIFO threshold is 'low'. I don't think it
> is a good thing to try to enter to lower C state to immediately jump out of
> it. With 0.02ms there is not much time we can spend conserving power and the
> enter/leave takes a bit more compared to staying wherever we were.
> ON the other hand, if we have big ALSA buffer we can keep the MPU off for a
> long time as we only need the DMA and the McBSP to run between user space
> filling the ALSA buffer...
> 
> Oh, I have looked again to cpuidle34xx.c and we have two tables there:
> omap3_idle_driver and omap3430_idle_driver.
> 
> The omap3430_idle_driver numbers are based on measurements while the
> omap3_idle_driver probably contains safe numbers?
> 
> 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.

> 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.

> >>> We hit C6, but when the DMA request comes we have 16 words in the FIFO (8
> >>> samples, 0.16ms of audio). C6 should take 11.5ms to exit...
> > 
> > So maybe we have the C6 latency for 36xx wrong, and it's much faster than
> > for 34xx? I wonder what happens on the original beagleboard, not the
> > xm variant.. I don't have one though.
> 
> I have one working omap3 zoom2 board. AFAIK it has OMAP3430. I have
> 3.9.smthing kernel booting on it, but I'm not sure if mainline would even
> work. Zoom3 and Zoom2 are mostly identical, but the SoC is different for sure
> and probably memories, NAND, something else on the SOM? Can not find
> information on this.

I would not bother with that one.. Chances are it has an older 3430
SoC that does not properly support off mode. We should be able to use
n900 for that test :)

> > Hmm OK I wonder why have not seen that one, I've been just hitting ctrl-c
> > to stop the playback.
> 
> I also stopped the playback with ctrl-c :o

Hmm I need to recheck.

Regards,

Tony