Andy This could be a signal integrity issue on your custom board, when you were using the AIC33 as a master to provide the ASP clock.
Thanks & Regards Mukul Bhatnagar DSP Catalog Applications (Houston) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ngo Sent: Tuesday, September 04, 2007 1:07 PM To: Praveen K H; Rudy Reinsch; davinci-linux-open-source @linux.davincidsp.com Subject: Re: Audio Driver Lockup Issue Hi, I have some good news (well, at least for our custom Davinci board). After 2 months of scratching our heads about the audio lockup problem, we think the lockup problem is fixed by doing a simple change: make the AIC33 codec a slave and the ASP (McBSP) the master. Currently, the audio driver code is configured such that the AIC33 is the master and the ASP is the slave. Well, over the weekend, I did a simple change by commenting out the macro #define AIC33_MASTER in linux/sound/oss/davinci-audio-aic33.c and rebuilt the kernel; I had a simple full-duplex test (read from audio device and then write the data back to it) running continuously over the weekend and not a single lockup occurred (usually, I would get a lockup within 30 minutes). I don't know why this fixes the problem; maybe when the ASP is the master, the timing is better synchronized? Maybe the 22Mhz clock to the AIC33 doesn't synchronize well with the Davinci ASP's clock? As mentioned by Praveen, I sometime see the lockup occurred when closing the audio device (audio_sync doesn't return); I commented out that code and that seems to fix that lockup. I don't know if this call is critical. Hopefully, this will resolve the audio lockup problem that everyone is seeing. Comments? Regards, Andy ----- Original Message ---- From: Praveen K H <[EMAIL PROTECTED]> To: Andy Ngo <[EMAIL PROTECTED]> Cc: Praveen K H <[EMAIL PROTECTED]> Sent: Friday, August 31, 2007 4:17:42 AM Subject: Re: Audio Driver Lockup Issue Hi Andy, Apart from audio_write, I have seen the lockups even while closing the device using close() call. On debugging further, figured out that the lockup is in audio_sync() function called from audio_release(). For now, I have put in three workarounds that are at least avoiding the lockups. 1. Remove audio_sync() from audio_release() function. 2. Before calling write() from my application, check if there are any free fragments available at the driver (using SNDCTL_DSP_GETOSPACE ioctl). If not, keep trying for 2-3 seconds and if it still is not available, close() and re-open() the driver. 3. I also added davinci_clean_channel() in the function sound_dma_irq_handler() if the status is not DMA_COMPLETE. This is for clearing the EMR and EMRH bits. Not sure if this one is helping. Although, this introduces a momentary lockup for 3 seconds, the system is at least able to recover and continue running. Please let me know if you make more progress with this issue. Thanks and Regards, Praveen K H Andy Ngo wrote: > 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 > > _______________________________________________ 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
