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

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

[Philip Chu]

HI,

I got a problem with my audio capture using McBSP 3 port on OMAP 3530. Linux kernel 2.6.32.
For the very first audio data capture, when I expect to receive only one exact period of data through McBSP, PCM DMA ISR never comes. When I check the DMA pointer by using snd_pcm_update_hw_ptr_pos(), I found it was just trash value. If I ask the data sender to send 4 samples more than the period defined, DMA ISR gets fired, the it points to the exact period position, and I assume the extra 4 bytes just get lost?

My McBSP is configured as a slave which needs the sender to provide Frame Sync, clocks etc, and those signals are designed to just kick in at the same time. Do the clock signal need to be present earlier than the Frame Sync?

Anybody knows what the issue could be?

Thanks in advance.

Philip Chu

Re: PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?

[Jarkko Nikula]

On Wed, 22 Jun 2011 00:04:43 -0500
Philip Chu <Philip.Chu@logicpd.com> wrote:

> HI,
> 
> I got a problem with my audio capture using McBSP 3 port on OMAP 3530. Linux kernel 2.6.32.
> For the very first audio data capture, when I expect to receive only one exact period of data through McBSP, PCM DMA ISR never comes. When I check the DMA pointer by using snd_pcm_update_hw_ptr_pos(), I found it was just trash value. If I ask the data sender to send 4 samples more than the period defined, DMA ISR gets fired, the it points to the exact period position, and I assume the extra 4 bytes just get lost?
> 
> My McBSP is configured as a slave which needs the sender to provide Frame Sync, clocks etc, and those signals are designed to just kick in at the same time. Do the clock signal need to be present earlier than the Frame Sync?
> 
> Anybody knows what the issue could be?
> 
Sounds like the last sample(s) may stay in McBSP receive shift register
and they get copied to receive buffer and forward only until the
receiver is running again.

I'm thinking is this missing interrupt due missing first sample. Do you
receive it and does the received data look correct?

It could be that the McBSP expects a stable bit-clock before frame-sync
until it starts to receive data into shift register. I'm not sure about
this.

Another reason could be that the DAI format is not correct. I.e. if
the transmitter has 0-bit data delay after frame-sync but McBSP is
configured for 1-bit so 1 bit is missing from shift register when the
transmission ends. But then just a single bit-clock cycle, not the full
word should kick the data forward and DMA ISR should occur.

-- 
Jarkko

Re: PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?

[Philip Chu]

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?
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.

And I think Frame Sync has to be a little later compared to the bit clock, but it should be only responsible for missing 1 samples in my case, because all my clock signals look to kick in at the same moment.


Thanks,
Philip


-----Original Message-----
From: Jarkko Nikula [mailto:jhnikula@gmail.com] 
Sent: Wednesday, June 22, 2011 3:05 AM
To: Philip Chu
Cc: Alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?

On Wed, 22 Jun 2011 00:04:43 -0500
Philip Chu <Philip.Chu@logicpd.com> wrote:

> HI,
> 
> I got a problem with my audio capture using McBSP 3 port on OMAP 3530. Linux kernel 2.6.32.
> For the very first audio data capture, when I expect to receive only one exact period of data through McBSP, PCM DMA ISR never comes. When I check the DMA pointer by using snd_pcm_update_hw_ptr_pos(), I found it was just trash value. If I ask the data sender to send 4 samples more than the period defined, DMA ISR gets fired, the it points to the exact period position, and I assume the extra 4 bytes just get lost?
> 
> My McBSP is configured as a slave which needs the sender to provide Frame Sync, clocks etc, and those signals are designed to just kick in at the same time. Do the clock signal need to be present earlier than the Frame Sync?
> 
> Anybody knows what the issue could be?
> 
Sounds like the last sample(s) may stay in McBSP receive shift register
and they get copied to receive buffer and forward only until the
receiver is running again.

I'm thinking is this missing interrupt due missing first sample. Do you
receive it and does the received data look correct?

It could be that the McBSP expects a stable bit-clock before frame-sync
until it starts to receive data into shift register. I'm not sure about
this.

Another reason could be that the DAI format is not correct. I.e. if
the transmitter has 0-bit data delay after frame-sync but McBSP is
configured for 1-bit so 1 bit is missing from shift register when the
transmission ends. But then just a single bit-clock cycle, not the full
word should kick the data forward and DMA ISR should occur.

-- 
Jarkko

Re: PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?

[Jarkko Nikula]

On Wed, 22 Jun 2011 10:26:28 -0500
Philip Chu <Philip.Chu@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.

> 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.


-- 
Jarkko

Re: PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?

[Péter Ujfalusi]

On Thursday 23 June 2011 08:50:13 Jarkko Nikula wrote:
> On Wed, 22 Jun 2011 10:26:28 -0500
> 
> Philip Chu <Philip.Chu@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

Re: 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@ti.com] 
Sent: Thursday, June 23, 2011 9:17 AM
To: alsa-devel@alsa-project.org
Cc: Jarkko Nikula; Philip Chu; Alsa-devel@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@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