[alsa-devel] ASoC: at91sam9260-PCM1808/TAS5709-based board driver

[Mark Brown]

On Fri, Aug 28, 2009 at 05:24:59PM -0400, Pedro I. Sanchez wrote:

> Well, it turns out that the TAS5709 documentation doesn't say the whole
> story. It seems that after all the chip can only guess the incoming bit
> rates in rare occasions and I can't really rely on this. What the chip
> really needs is a MCLK signal which is a multiple of the sound file's
> sample frequency. This is a third clock line to be provided to that chip in
> addition to the regular TF (frame) and TK (bit) clocks from the SSC
> interface.

That's fairly standard for CODECs - some have FLLs or similar which
allow them to generate their master clock from the BCLK or LRCLK but
most need a MCLK too.

> Now I know that I have to output this additional clock line via one of the
> gpio pins of the SoC and therefore I have to somehow "attach" one of the
> CPU internal timers to one of the SoC gpio pins (PC6, linux gpio102 pin to
> be more exact). I have the following (borrowed) code now:

Be careful here.  Generally CODECs require some synchronisation between
the master clock and the other audio clocks - normally the controller
block in the CPU will have a clock it can provide with the intention
that it be used as a master clock.

> 	/* PCK0 provides MCLK */
> 	at91_set_A_periph(AT91_PIN_PC6, 0);

> How is this linking the internal pck0 timer to pin PC6? or is it?

You'd be better off asking the Atmel people on linux-arm-kernel (or some
other Atmel-specific list if there is one) about this - it's more of a
general question about the CPU port than an audio-specific question.

>         ret = clk_set_parent(mclk, pllb);
>         if (ret != 0) {
>                 pr_err("%s: Failed to set MCLK parent\n", __func__);
>                 goto err_parent;
>         }

>         clk_set_rate(mclk, 11289600);
>         clk_put(pllb);
>         pr_info("%s: MCLK rate %luHz\n", __func__, clk_get_rate(mclk));

> ... but it prints "MCLK rate 6000000Hz". Where does the 600000 come from, I
> don't know. And certainly there is no clock on the PC6 pin :-(

It'll be derived from the parent clock plus any dividers in the way.