[alsa-devel] PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?

[Philip Chu]

Thanks very much for both of your reply.

I got our customer to provide extra bit clocks before Frame Sync signal kicks in and also after the data signal ends. In both ends an extra frame of bit clocks are added, then McBSP is seeing all data without missing any bit.

So I guess the DMA is moving forward with every frame coming out of MCBSP, but the latest DMA pointer will not be valid until the very first period ISR happens. Thus when missing sample happens, DMA may not get anything is McBSP is 
receiving fewer than one period of frames.


Thanks,
Philip


-----Original Message-----
From: Péter Ujfalusi [mailto:peter.ujfalusi at ti.com] 
Sent: Thursday, June 23, 2011 9:17 AM
To: alsa-devel at alsa-project.org
Cc: Jarkko Nikula; Philip Chu; Alsa-devel at alsa-project.org
Subject: Re: Re: [alsa-devel] PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?

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.

-- 
Péter