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

Pavel Machek pavel at ucw.cz
Fri Sep 2 17:54:37 CEST 2016


Hi!

> >> When the FIFO is set to 128, it means that after the initial FIFO fill we will
> >> have DMA request coming from McBSP to sDMA with a rate of:
> >>
> >> (1000/sampling_rate) * (FIFO-threshold / channels) = DMA_req_distance_in_ms
> >>
> >> So in case of 44.1KHz, stereo with 128 FIFO threshold DMA request will come at
> >> every 1.45ms. If I'm not mistaken. The whole FIFO (1280) holds 14.51ms of
> >> audio in this case.
> >>
> >> I don't see this correlate with the 30ms at all.
> > 
> > It seems we easily have a situation where DMA is done buffering to McBSP,
> > and PMIC is playing audio, and we hit idle. At that point there are no immediate
> > timers pending and cpuidle determines we can try to hit a deeper idle mode. As
> > there are no hardware blockers with DMA off and McBSP not blocking, the hardware
> > hits off mode. This cuts power to McBSP.
> > 
> > Ideally we'd configure McBSP activity to block deeper idle states in the
> > hardware but I don't think we have such a configuration available.
> 
> I wonder why we have not seen this before? I can not recall anything like this
> with n900 (Jarkko might know that better) neither with n9/n950. On the n9/n950
> I have even put the OMAP3 to OFF during audio playback with the

I was seeing something like that with 4.x kernel on Nokia N900.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


More information about the Alsa-devel mailing list