On Wednesday 19 May 2010 11:31:57 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
So the latency is the length of the McBSP FIFO.
[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
The latency depends on when you are asking. When the FIFO is full, than you have maximum latency, right at the end of the drain phase, you will have the shortest latency.
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.
So it is not that clear how to view them ;)