[alsa-devel] Problem about developing WM8974 audio driver for MX27ipcam
Hi all,
I'm developing a driver for wm8974 codec with Freescale mx27ipcam board with linux kernel 2.6.19.2. Our work is based on the mx27vis-wm8974 driver available in alsa-driver-1.0.22.
After installing all necessary driver modules, when I trying to playback some wav file using "cat xx.wav > /dev/dsp" command, I got the following error message: "ALSA pcm_lib.c:1709: playback write error (DMA or IRQ trouble?)".
This seems to be caused by the full of the transmitting buffer since I can check that "hw_ptr=0x800/buffer_size=0x4000/appl_ptr=0x4800". The hw_ptw doesn't update anymore. It seems that there is something wrong with the DMA operation. Actually, the DMA dest. address is the SSI1's TX0 FIFO. On the other hand, SSI1's SFCSR=0x440844, which indicates that there are 8 bytes data in the TX0 FIFO, which will not generate DMA request as the FIFO empty watermark is 4. It is very possible that the SSI1 does not shift data from the FIFO, which causes no DMA request generated and thus DMA freezes.
Our board connects wm8974 codec to mx27 gpio PC20~23 pins (signal name are SSI1_XXX). On these io pins, we can check the FS and bit clock have been generated. The PC20~PC23 gpio pins have been configure as SSI function. My driver also configures AUDMUX host port1(HP1,wired to SSI1 internally) to peripheral port 1(PP1). But I'm not sure whether PP1 is mapped to PC20~23. Is this configuration right? If this map is wrong, the FS and Bit Clock generated by wm8974 can not be routed to SSI1 module, which is the potential reason for no data are shifted.
Who can shed some light on the map between mx27 AUDMUX port and GPIO pins? Any more possible reasons which will freeze DMA transfer?
Regards, Jie
On Sat, May 08, 2010 at 11:04:05AM +0800, Jie Jiang wrote:
After installing all necessary driver modules, when I trying to playback some wav file using "cat xx.wav > /dev/dsp" command, I got the following error message: "ALSA pcm_lib.c:1709: playback write error (DMA or IRQ trouble?)".
This seems to be caused by the full of the transmitting buffer since I can check that "hw_ptr=0x800/buffer_size=0x4000/appl_ptr=0x4800". The hw_ptw doesn't update anymore. It seems that there is something wrong with the DMA operation. Actually, the DMA dest. address is the SSI1's TX0 FIFO. On the other hand, SSI1's SFCSR=0x440844, which indicates that there are 8 bytes data in the TX0 FIFO, which will not generate DMA request as the FIFO empty watermark is 4. It is very possible that the SSI1 does not shift data from the FIFO, which causes no DMA request generated and thus DMA freezes.
As you've diagnosed below this normally indicates that the clocking for the bus isn't set up correctly and the clocks aren't reaching the bus and therefore DMA controller on the CPU.
Who can shed some light on the map between mx27 AUDMUX port and GPIO pins? Any more possible reasons which will freeze DMA transfer?
Bad clocking is the main one. What I do when diagnosing similar problems is either try to route the data and clocks out to another external port on the AUDMUX (so you can see what's actually getting through) or write code to read back the device settings and translate them into human readable form (you can see some debugfs files I did for the i.MX3x AUDMUX in mainline) which often helps discover incorrect settings.
Sasha Hauer, who did the mainline drivers for i.MX, may also be able to help - I've CCed him.
participants (2)
-
Jie Jiang -
Mark Brown