Hi Andy,
Thanks for the detailed response. Have you figured out any workaround
for this issue. It would be great if you can share any other inputs that
you have for this problem.
Thanks and Regards,
Praveen K H
Andy Ngo wrote:
Hi,
I have similar audio stalling problems that have been nagging me for a couple months! Like you, I've have playback stalling problem (in which my application hangs on writing to the audio device - i.e. the call to write(dspFd,...) doesn't return) as well as record stalling problem (in which my application hangs on reading from the audio device - i.e. the call to read(dspFd,...) doesn't return). I'm using the 2.6.20 GIT version on our custom Davinci board, in which the audio hardware is hooked up like the DVEVM; I haven't tried out the Montavista version because it doesn't have support for the NOR JFFS2 driver I need for our custom board. These problems have been driving me nuts and TI tech support (Juan Gonzales is one of the best DSP Applications experts at TI) is is currently helping me.
Well, I have been trying to track the source of the problem is by looking down to the ASP (Audio Serial Port) hardware level. Here's an email I sent to TI just a few days ago:
---------------- start of email ------------------
Hi Juan,
I tracked the read stall down to a Receive Overrun (RFULL) condition on the McBSP serial bus. If you look at the Audio Serial Port (ASP) Interface data sheet (SPRUE29), there is a Serial Port Control Register (SPCR - physical address 0x01E02008) that shows the transmit and receive status of data to and from the AIC33 codec. When the read operation works properly, Bit 2 (RFULL) of the SPCR register is never set. However, when the read stall occurs on our custom bread board (audio data path from Davinci to AIC33 is longer), this bit is always set:
Serial Port Control Register (SPCR):
Bit2 RFULL Receive shift register full bit.
0 RBR is not in overrun condition.
1 DRR is not read, RBR is full, and RSR is also full with new word.
Here's the description about RFULL from SPURE29:
2.4.5.1 Receive Overrun: RFULL
RFULL = 1 in the serial port control register (SPCR) indicates that the receiver has experienced overrun
and is in an error condition. RFULL is set when the following conditions are met:
· DRR has not been read since the last RBR-to-DRR transfer.
· RBR is full and an RBR-to-DRR copy has not occurred.
· RSR is full and an RSR-to-RBR transfer has not occurred.
The data arriving on DR is continuously shifted into RSR (Figure 21). Once a complete element is shifted
into RSR, an RSR-to-RBR transfer can occur only if an RBR-to-DRR copy is complete. Therefore, if DRR
has not been read by the CPU or the EDMA controller since the last RBR-to-DRR transfer (RRDY = 1), an
RBR-to-DRR copy does not take place until RRDY = 0. This prevents an RSR-to-RBR copy. New data
arriving on the DR pin is shifted into RSR, and the previous contents of RSR are lost. After the receiver
starts running from reset, a minimum of three elements must be received before RFULL can be set,
because there was no last RBR-to-DRR transfer before the first element.
This data loss can be avoided if DRR is read no later than two and a half CLKR cycles before the end of
the third element (data C) in RSR, as shown in Figure 22.
Either of the following events clears the RFULL bit to 0 and allows subsequent transfers to be read
properly:
· Reading DRR
· Resetting the receiver (RRST = 0) or the device
Per this description, for this overrun condition to occur, it seems like the DMA read operation (probably from davinci_mcbsp_recv_buffer) didn't read the DRR since the last RBR-to-DRR transfer (hence, the wait_for_completion_interruptible in audio_read never returns). Do you think this is a DMA issue? Since our test application is continuously reading from the audio device, it seems like the DMA is in a state in which it's not reading the DRR, the only way to recover is to reset the receiver or the device. Please advise.
On our stacked cards board (audio data path from Davinci to AIC33 is shorter), we infrequently see the write stall problem. I haven't had a chance to dump the SPCR register when write stall occurs but I'm suspecting it's the opposite of the read stall problem above. In the write stall problem case, I believe it's an underflow problem and that Bit18 (XEMPTY) is always clear (and Bit17 (XRDY) is always set) because the DMA write operation (probably from davinci_mcbsp_xmit_buffer) didn't write to the DXR since the last DXR-to-XSR copy.
---------------- end of email ------------------
This is down at the low level but it propagates up to audio driver where the
DMA requests are being called. For the write stall problem, the call to
wait_for_completion_interruptible in audio_write (in
linux/sound/oss/davinci-audio.c) never returns; similarly, for the read stall
problem, the call to wait_for_completion_interruptible in audio_read never
returns.
I tracked the problem down to these specific areas but I'm not sure about the
exact cause: timing issue? DMA issue? Hopefully by providing this information
someone may have figure out this nagging stalling issue. Please help... anyone!
I'm almost desperate to go to 2.6.23 GIT to see if it resolves the problem but
I don't want to introduce any unknown issues to our system.
Regards,
Andy
----- Original Message ----
From: Praveen K H <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, August 22, 2007 8:50:24 AM
Subject: Audio Driver Lockup Issue
Hi,
We have been observing a strange problem with the Audio driver in
Davinci (Both MontaVista and GIT). The driver seems to lock up sometimes
in the write call.
To simulate the issue, I tried the following.
# cat file1.pcm > /dev/dsp
# cat file1.pcm > /dev/dsp
When the second cat starts, there is no audio output and we observed
that the cat is blocking in the write call. Tried enabling debug prints
in davinci-audio.c and davinci-audio-dma-intfc.c . The output of the
second command is attached at the end of this mail. Please note that the
"sound_dma_irq_handler" is not getting called. But, in the first
iteration, the irq handler is getting called. This problem is very
consistent.
Has anyone faced this problem. Any inputs ???
Thanks and Regards,
Praveen
# [davinci_audio.c:[audio_open] start
DMA REQUEST FOR playback
[davinci_request_sound_dma]: start
<davinci_request_sound_dma>: Master chan = 2
[davinci_request_sound_dma]: end(0)
SETUP FOR PLAYBACK
[audio_reset]: start
[audio_reset]: end(0)
[davinci_audio.c:[audio_open] end(0)
audio_write: count=8192
[audio_setup_buf]: start
[audio_setup_buf]: end(0)
write 3072 to 0
[audio_process_dma]: start
[davinci_start_sound_dma]: start
[audio_set_dma_params_play]: start
<audio_set_dma_params_play>: audio_set_dma_params_play channel = 72
dma_ptr = 827b0000 dma_size=c00
[audio_set_dma_params_play]: end(0)
[audio_start_dma_chain]: start
[audio_start_dma_chain]: end(0)
[davinci_start_sound_dma]: end(0)
[audio_process_dma]: end(0)
write 3072 to 1
[audio_process_dma]: start
[davinci_start_sound_dma]: start
[audio_set_dma_params_play]: start
<audio_set_dma_params_play>: audio_set_dma_params_play channel = 73
dma_ptr = 827b0c00 dma_size=c00
[audio_set_dma_params_play]: end(0)
[audio_start_dma_chain]: start
[audio_start_dma_chain]: end(0)
[davinci_start_sound_dma]: end(0)
[audio_process_dma]: end(0)
write 2048 to 2
audio_write: return=8192
audio_write: count=8192
write 1024 to 2
[audio_process_dma]: start
[davinci_start_sound_dma]: start
<davinci_start_sound_dma>: queue full
[davinci_start_sound_dma]: end(4294967294)
<audio_process_dma>: error
error
[audio_process_dma]: end(4294967294)
write 3072 to 3
[audio_process_dma]: start
[davinci_start_sound_dma]: start
<davinci_start_sound_dma>: queue full
[davinci_start_sound_dma]: end(4294967294)
<audio_process_dma>: error
error
[audio_process_dma]:
end(4294967294)
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
