On Thu, May 27, 2010 at 01:47:03AM +0100, Mark Brown wrote:
> On Wed, May 26, 2010 at 11:21:36PM +1000, Stuart Longland wrote:
>
> > At the moment, when I go to play audio; I see the CODEC being set up ...
> > but despite the clocks being present -- I see no audio data, and the DMA
> > transfer eventually times out with the message "playback write error
> > (DMA or IRQ trouble?)" after 10 seconds. Would anyone know where I'd
> > look for that? Is there something else needed in the configuration of
> > the SSI driver for this to work?
>
> This most likely means your CPU side configuration is broken and clocks
> aren't being routed through. Try looking at the AUDMUX debugfs files to
> verify your configuration, and also try routing out to another external
> SSI port so you can probe signals. Make sure the relevant pins on the
> i.MX are configured into the appropriate mode for use by the i.MX too.
>
> Note also that the current driver only supports CODEC as clock master.
I figured this might be the case, now to figure out why the clocks
aren't getting through.
The CODEC chip we're using can work either way; I²S master or slave. So
switching it to work the other way is an easy proposition. My work thus
far has been using the CODEC as master. The CODEC however, sources its
clock (on MCLK) from the clock pin on SSI3.
I have a userspace application that mmaps the registers for SSI2 and
AUDMUX, and sets this up, so no big deal ... the clock it receives is
about 12.1MHz (12.093MHz according to the frequency counter here).
Ka-Ro's TX27 module don't make any other SSI ports accessible (to my
knowledge). So in that regard; I can't directly test using the above
method. However, I have tried something similar. The TLV320AIC3204
CODEC IC can route clocks from a secondary audio interface. Using IÂC
commands, I was able to tell it to pretend its "GPIO" pin was the
secondary audio interface bit clock -- this pin is connected to the SSI4
interrupt line; and is being weakly pulled up by the i.MX27.
The CODEC therefore routed this out on its BCLK pin, connected to
SSI4_CLK. I told AUDMUX to route this through to SSI3_CLK and watched
that on the CRO. So to clarify (please forgive the ASCII-art)...
Pull-up: :
| : :
i.MX27 SSI4_INT <<<--+-:----+-----------------:-----+-->>> GPIO CODEC
AUDMUX : '--> Probe to 0v : |<-- Internal link
SSI4_CLK <<<--+-:----------------------:-<<<-+----- BCLK
Internal Link---->| : :
SSI3_CLK >>>--+-:----+-----------------:->>>------- MCLK
'--> CRO
Whenever I touched the probe to 0v; the MCLK dropped almost
immediately... I was not able to measure the delay on the scope here.
When I try to play audio; the AUDMUX configuration is as follows:
Port: imx-ssi.0
Raw: cb205000
TxFS output from SSI4, TxClk output from SSI4
Port is symmetric
Data received from SSI4
Port: imx-ssi.1
Raw: 00001000
TxFS input, TxClk input
Port is symmetric
Data received from imx-ssi.0
Port: SSI4
Raw: 00001000
TxFS input, TxClk input
Port is symmetric
Data received from imx-ssi.0
Port: SSI1
Raw: 00001000
TxFS input, TxClk input
Port is symmetric
Data received from imx-ssi.0
Port: SSI2
Raw: 00001000
TxFS input, TxClk input
Port is symmetric
Data received from imx-ssi.0
Port: SSI3
Raw: c4103000
TxFS output from imx-ssi.1, TxClk output from imx-ssi.1
Port is symmetric
Data received from imx-ssi.1
I'll have a look at the Eukrea CPUIMX27 and baseboard SoC support in a
moment, since it looks very similar to what we're doing (in that it's a
TI I²S CODEC hooked to an i.MX27 on SSI4) ... this might reveal clues
as to what I'm doing wrong.
--
Stuart Longland (aka Redhatter, VK4MSL) .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer '.'` :
. . . . . . . . . . . . . . . . . . . . . . .'.'
http://dev.gentoo.org/~redhatter :.'
I haven't lost my mind...
...it's backed up on a tape somewhere.