On Sun, 2009-02-22 at 22:47 +0100, Daniel Mack wrote:

Hi,

I'm currently implementing support for a board based on a PXA300 with an I2S codec (CS4270) next to it. Things do work in general, including the setup of the SSP engine and clocks, and when using the OSS compat layer, I can see data on the bus. With the native ALSA API, however, the DMA pointer does not move forward but is stuck at position 8. ALSA's core calls pxa2xx_pcm_pointer() a couple of times and eventually gives up on it. Unfortunately, I don't have a Zylonite board for cross-check; could anyone verify that things are not currently broken in a general way?

My code base is up-to-date to sound-2.6.git/for-2.6.30.

Can't test on my zylonite atm, but static DMA pointers usually mean data is not being clocked out of the SSP FIFO. Can you check you are supplying a BCLK and LRC to the SSP port (if codec is BCLK/LRC master) or have enabled the PXA SSP master mode (if codec slave).

Liam

On Sun, Feb 22, 2009 at 10:47:21PM +0100, Daniel Mack wrote:

I2S codec (CS4270) next to it. Things do work in general, including the setup of the SSP engine and clocks, and when using the OSS compat layer, I can see data on the bus. With the native ALSA API, however, the DMA

One other thing to check here is that because the OSS API will iterate through several different calls to hw_params() since it sets each parameter individually it's possible that the configuration done in one of the intermediate states is causing your configuration to spring to life. It might be worth looking at what's different about the setup done by the OSS API and working back from there.