Mukul / Brad, Thanks for the recommendations; when the audio read stall occurred, I dumped the EMR, EMRH and SER registers and all the bits are 0 so no missed EDMA event has occurred; hence, it may not be an EDMA issue. Today, I had a conference call with a few TI experts (one Davinci expert, one ASP expert, and a DSP expert) and they recommended a few things 1) make sure the audio signals (frame sync, clock, rx/tx data) look OK 2) make sure the ARM clock is at least 200Mhz (we're using 162Mhz) 3) check Davinci errata 215. I'll keep those with the same issue up to date. Any other suggestions, anyone?
Thanks. Regards, Andy ----- Original Message ---- From: "Bhatnagar, Mukul" <[EMAIL PROTECTED]> To: Andy Ngo <[EMAIL PROTECTED]> Sent: Thursday, August 30, 2007 1:38:37 PM Subject: RE: Audio Driver Lockup Issue Andy Brad Griffis asked you to check the EMR registers, can you also check the SER registers. It is at the following location 0x01c0 2238 (SER) You should ensure that bits number 2 and 3 (for XEVT and REVT channels) are not set in the SER register, when you see the audio driver stall. Thanks & Regards Mukul Bhatnagar DSP Catalog Applications (Houston) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ngo Sent: Wednesday, August 22, 2007 8:48 PM To: Praveen K H; [email protected]; [EMAIL PROTECTED] Subject: Re: Audio Driver Lockup Issue 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 _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
