[alsa-devel] PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?
peter.ujfalusi at ti.com
Thu Jun 23 15:16:32 CEST 2011
On Thursday 23 June 2011 08:50:13 Jarkko Nikula wrote:
> On Wed, 22 Jun 2011 10:26:28 -0500
> Philip Chu <Philip.Chu at logicpd.com> wrote:
> > Thanks for your help.
> > How big is the chance that McBSP will have samples remaining in its
> > shift registers, not to its FIFO until next time it receives new data
> > samples?
> I suppose none if McBSP framesize (wlen * channels) number of bitclock
> cycles (+ possible 1-bit data delay) are received after framesync.
Should not IMHO either.
Could you provide information on your configuration, like number of channels,
sample size, format (I2S, DSP_A/B, etc).
If you can, probably a dump of McBSP register content might help as well.
Is it possible to check for you the place of the missing 4 samples, when you
send 4 sample more? Is it missing from the start or from the end of the block?
> > My PCM DMA is running in element mode so it sets up FIFO threshold as 1
> > (0 in the register). That means FIFO should pass the data as long as it
> > sees them coming.
> > Before the very first DMA ISR (completed a period of data transfer by
> > DMA), the DMA pointer is a void number, I think it means DMA has not
> > ever completed one entire period transfer yet. My suspection is, does
> > DMA need some time to be ready for receiving data from McBSP's DMA
> > event? If it does need some time, then the very first a couple of
> > sample(s) from McBSP could be missed.
> Indeed, this is actually strange that DMA pointer is not updated. How
> big is your period size? Is it smaller than DMA burst size which is set
> to 64 bytes in sound/soc/omap/omap-pcm.c? I'm not sure does the DMA use
> burst transfer in element mode but non-updating pointer is kind of
> indicating that there is neither DMA transfer going on until enough
> data is received.
Yeah, the DMA pointer should move, even if you do not receive the period
interrupt, since you are in element mode, so you should be reading from McBSP
FIFO word by word.
McBSP is looking for start condition to shift in or out bits, so it could be
that you might need to have bit clock running before you start the transfer
(with asserting the FS). Just to be sure, that McBSP recognizes the change on
the FS line.
More information about the Alsa-devel