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@slimlogic.co.uk 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html