On Wed, May 19, 2010 at 10:31:57AM +0200, Ujfalusi Peter (Nokia-D/Tampere) wrote: > On Wednesday 19 May 2010 08:13:25 ext Jarkko Nikula wrote: > > On Tue, 18 May 2010 21:13:10 +0100 > > > > Liam Girdwood <lrg@xxxxxxxxxxxxxxx> wrote: > > > I've also added a patch to remove the mcbsp DMA op mode sysfs set > > > functionality. I think DMA op mode is very specific to the mcbsp client > > > driver _only_ and shouldn't really be changed by userspace. Please let > > > me know if you use this feature and I'll drop this patch. > > > > I've used to say that the DMA op mode is more like use-case not machine > > specific but I'm not sure is my point valid onemore. I've used to think > > that low-latency processing would need accurate DMA pointer (op > > mode == element) while mp3 playback would need low power consumption > > (op mode == threshold). > > Yeah, it used to be so clear ;) > I see these: > element mode: if user want to have constant latency [1] > threshold mode: variable latency, but possibility to save power [2] > > [1] The McBSP is kept full during playback (and empty during capture) > The DMA pointer moves word-by-word > > [2] The McBSP FIFO fill rate changes (full, drain, refill, full, drain...) > The DMA pointer moves in bursts. > Between burst memories can relax, core, MPU also in theory. > Smart idle helps to conserve more power here > > > Peter: what's the status today how well can we do low-latency > > processing with threshold mode? IRCC, with your FIFO delay query > > patches, can we estimate the DMA pointer position with enough accuracy? > > The DMA pointer is easy, and it was know before as well, but according to my > tests, the McBSP FIFO caused delay reporting is fairly accurate. > I'll ask my users, if they have done some additional tests. OK. fair enough. What if you really want to avoid the delay at all? > > -- > Péter > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
