pxassp dma pointer not moving

pxassp dma pointer not moving

[Daniel Mack]

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.

Thanks and best regards,
Daniel

Re: pxassp dma pointer not moving

[Liam Girdwood]

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

Re: pxassp dma pointer not moving

[Liam Girdwood]

On Sun, 2009-02-22 at 23:16 +0100, Daniel Mack wrote:
> Hi Liam,
> 
> On Sun, Feb 22, 2009 at 10:07:57PM +0000, Liam Girdwood wrote:
> > > 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).
> 
> All the clocks are there, they're only driven by the Codec, and they look
> fine. And thus, the CPU DAI is set to SND_SOC_DAIFMT_CBM_CFM.
> 
> What puzzles me is that the whole system works when I cat /dev/urandom
> to /dev/dsp (the DMA pointer is moving forward just as expected), only
> when using aplay it doesn't do anything.

Ah, Please see later email re buildroot. Interestingly someone had
exactly the same issue (on OMAP iirc) with buildroot alsa-lib on
#alsa-soc last week.

Liam  

Re: pxassp dma pointer not moving

[Mark Brown]

On Sun, Feb 22, 2009 at 10:07:57PM +0000, Liam Girdwood wrote:

> Can't test on my zylonite atm, but static DMA pointers usually mean data

The zylonite hardware only supports codec as slave, unfortunately.

> 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).

It's also worth checking that the clocking is OK and that there are enough
BCLKs per LRCLK being generated by the codec if the codec is master.

Re: pxassp dma pointer not moving

[Mark Brown]

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.