Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Jarkko Nikula <jhnikula@gmail.com>]

Sorry for the late reply.

On Thu, 6 Aug 2009 20:15:40 +0200
<ext-Eero.Nurkkala@nokia.com> wrote:

> Well, the element mode is fine for !McBSP2. One doesn't really loose the
> buffer pointer accuracy, because you can get the last DMA irq timestamp
> with SNDRV_PCM_IOCTL_TTSTAMP (and compare that to current time).
> The accuracy is not far off from the element mode? (If you read the DMA
> portion of TRM, I think there were some issues as well)
> 
Well the threshold mode makes the offset returned from omap_pcm_pointer
to behave gradually as the threshold size is set. This would affect a SW
which is doing sub-period processing like mixing audio n samples ahead
the current DMA pointer. Of course HW buffer in McBSP2 adds static
latency but otherwise processing is similar compared to other ports and
OMAPs.

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.

> For !McBSP2, it doesn't even pay to have the threshold mode at all, because
> the effect on PM is actually adverse - too frequent wakeups will cause more
> adverse net effect on PM (IIRC) @ VBAT.
> 
This is good information and integrating these functionalities allow to
collect more. Without regression of course :-)


-- 
Jarkko