![](https://secure.gravatar.com/avatar/e507159b016ae5fe4e2fa9e7d677bc10.jpg?s=120&d=mm&r=g)
On Tue, 11 Aug 2009 09:18:01 +0300 Eero Nurkkala ext-eero.nurkkala@nokia.com wrote:
I would like to see this new threshold based transfer functionality to be integrated so that projects can take the advantage of it and helps generic PM development too but I don't want that it would cause any regression now. Later on it is easy to switch threshold based transfer to be the default for McBSP2 on OMAP3 but it's safer to keep current mode default over one kernel release.
What regression are you addressing to? Of course in OMAP2s there could be issues I'm not aware of. But does this have any effect on them? (isn't this only OMAP3).
A possible regression to a SW which is using McBSP2 on OMAP3. There many of those boards.
The threshold based transfer will cause that omap_pcm_pointer will loose a bit its accuracy. Probably irrelevant but still better to play safe at least over one kernel release before making it default.
Return value prints from omap_pcm_pointer while playing "aplay -f dat /dev/zero"
element: 614 669 691 712 734 755
threshold: 512 512 512 1024 1024 1536