Hi all,

We are interested in using the Line-in inputs to sample a few audio signals.

Easy enough but we need to ensure good time alignment between these audio samples and bunch of other signals sampled by our hardware. We need better than 0.5 seconds over 12 hours - so better than about 11 ppm maximum average sampling clock error.

I assume that the oscillator providing the audio sampling clock has a pretty loose tolerance - +/-100 ppm maybe?

Alternatively we may be able to use the 18.432 MHz output from the Snapper in some fashion.

Two questions:
1) Is there any data on how clean this 18.432 MHz clock is? Jitter/phase noise? How is it generated? Is the original source a clean crystal and what happens in-between (just nice clean divisions, or is there a "noisy" PLL in the way)?

2) Are there any details available on enabling this clock output on PC1 under Linux.

Many thanks,
Ian

The 18.432mhz oscillator has a 30ppm tolerance at 25 degrees C. The oscillator for the ISL1208 realtime clock on the Snapper 9260 has a 20ppm tolerance.

We have had other customers use external devices, such a GPS modules, to provide higher accuracy for time stamping.

~Ryan

Thanks Ryan.


I can already generate a suitable time signal to allow me to measure the relative drift - but unfortunately that would not help me. I have no suitable and practical method of applying a correction. I haven't got the resources to reconstruct and re-sample (in a digital filter) (there are lots of channels) and the channels need to be aligned when stored.

So I am interested in potentially using the 18.432 MHz signal if it is clean enough and it can be made available as per Snapper 9260 datasheet. That would become the system sampling reference clock and remove the problem. I just need a bit of help, then, getting it driving the Snapper Module PC1 pin under Linux.

Thanks,
Ian

There was a discussion recently on the ARM kernel list about enabling accurate clocks on gpio pins. See here: [lists.arm.linux.org.uk]

If you want to enable PCK0 on PC1 you can add the following function to arch/arm/mach-at91/board-snapper9260.c and call it from sn9260_board_init:

static void __init enable_pck0(unsigned long rate_hz)
{
	struct clk *pck0, *pll;

	at91_set_B_periph(AT91_PIN_PC1, 0);
	pck0 = clk_get(NULL, "pck0" );
	pll = clk_get(NULL, "plla" );
	clk_set_parent(pck0, pll);
	clk_set_rate(pck0, rate_hz);
	clk_enable(pck0);
}

The alternative approach for generating clocks on the gpio pins is to use the timer counter peripheral. We have a driver for generating pwm clocks using the timer counters in our 2.6.20 kenrel. We can look at porting this driver into our 2.6.29 kernel if it would be useful.

~Ryan

I know this is an old issue and thanks Ryan for your reply.

When I enabled the audio MCLK on PC0 I measure it as something around 11 MHz not the 18.432MHz that the Snapper 9260 data sheet says it should be.

Any ideas?

Thanks,
Ian

PCK0 and PCK1 are programmable clocks. You can set the clock rate in hertz by using the clk_get_rate function in the Linux kernel, for example:

struct clk pck0;

pck0 = clk_get(NULL, "pck0" );
clk_set_rate(pck0, 18432000);
clk_enable(pck0);

Will set PCK0 to 18.432Mhz and enable it.

See the Atmel AT91SAM9260 Users' Guide for more details on how the clocks on the Snapper 9260 work.

Ryan, thanks for the reply.

I am aware of the clk_set_rate function.

I guess I am more asking why the clock is running at 11.something MHz when the Snapper 9260 datasheet says it should be running at 18.432 MHz - the freq that TI AIC chip is expecting.

Does this mean that I haven't got the audio configured correctly? I thought I had (correctly) enabled the driver in the kernel and rebuilt.

Thanks,
Ian

The Snapper 9260 audio driver (see sound/soc/at91/snapper9260.c) sets the PCK0 rate to 12mhz. The clk_set_rate function will set a clock to the closest possible rate. PCK0 probably ends up closer to 11mhz due to dividing off PLLA.

You can see the clock settings by enabling CONFIG_DEBUG_FS in your kernel config and then doing the following in Linux:

mkdir /debug
mount -t debugfs debugfs /debug
cat /debug/at91_clk

(I am not sure if the first copy of this got through the anti-spam filter, sorry for the repeat if it did.)

Hi Ryan,

Is there a pitch error in the recorded/played back audio then? Sorry for being a bit thick. I come from a hard real-time background with bare metal systems. I get the clock rates I want as I have designed the hardware and firmware system to achieve them.

I can understand the system providing the closest clock it can, but in a case where this feeds hardware which is expecting a specific frequency for correct operation there is a problem.

I assume that this is not the case with the Snapper 9260. That is, it does work correctly and there is something I just don't follow.

I am trying to work out why the Snapper 9260 data sheets mentions 18.432MHz and being able to output this on the PC1 port (pin 35 of the SODIMM)? Section 3.3.7 of the datasheet.

Thanks, Ian

Section 3.3.7 of the Snapper 9260 datasheet is incorrect. It should read "The clock for the audio CODEC is provided from Programmable Clock 0, available on CPU port PC1." Apologies for the misunderstanding.

The 18.432mhz crystal signal is not directly accessible from the Snapper 9260. The programmable clocks and the timer counter peripheral provide user configurable clocks which are divided from the PLLs.

The clock value used for PCK0 in the Snapper 9260 audio may not be as accurate as possible (the value was probably copied from one of our earlier AT91SAM9260 designs). Feel free to tweak the value if the audio rate is not accurate enough :-).

Ryan,

I have a bunch more questions on this, sorry, ...

1) PCK0 does drive the TI TLV320AIC23 audio codec on the module, doesn't it?

2) On a standard Snapper 9260 what is the PCK0 frequency?

3) I assume the Linux '320AIC23 driver is configured for this frequency?

4) If I change the PCK0 frequency I assume I will have to inform, or modify, the codec's driver.

5) A PCK0 frequency of 18.432 MHz (as per the Snapper data sheet that we were relying on) would be OK for our purposes and is a standard frequency for the codec. What is involved in getting Linux, the PCK0 output and the codec driver all working happily at this rate

Also, when I tried to change the PCK0 freq with clk_set_rate it didn't work. I am assuming the audio driver, or some other configuration function, must be called after the board setup function.

And, when I try to play a simple wav file using the instructions on the FAQ I get an error stating:
"set_sample_rate_control:Invalid rate 44100,44100 requested"

Thanks for your ongoing assistance,
Ian

Ian,
Sorry for the delay. I can confirm that PCK0 does drive the MCLK on the TLV320AIC23 audio codec. I will come back to you with answers on your remaining questions in the next few days.

Regards,
Andre

Hi Ryan and/or Andre,

Is there any news on this issue(s)?

Would it help to discuss this off line?

Thanks,
Ian

Still no news on this?

Thanks,
Ian

Just to clear this up so anyone having a similar issue knows what I was doing wrong, here is the solution for my troubles:

1) I needed to edit snapper9260.c in the kernel sound branch
".../sound/soc/atmel/snapper9260.c"
The changes required were to set the PCK0_RATE #define to 18432000 and a small edit in the sn9260_init function - change the parent clock to "main", rather than "plla". So the relevant section looks like:

if (cpu_is_at91sam9g20())
		pll_clk = clk_get(NULL, "pllb" );
else
		pll_clk = clk_get(NULL, "main" );  /* was"plla" */
if (IS_ERR(pll_clk)) {
		ret = PTR_ERR(pll_clk);
		goto fail;
}

Once this was done I could play suitable wav files with aplay. With 18.432MHz MCLK the AIC32 can't play 44.1kHz sample rate files (or 22.05kHz or 11.025kHz etc). So you need to test with a 48kHz file (or 8, 16, 24, 48, 96).

The 18.432MHz clock was then available on the module's PC1 pin. The level is a little low so buffering or pullup may be needed (in our case about 0.2 to 2V swing).

The clock is enabled/disabled by the sound driver. If you need it permanently enabled the "clk_enable" and "clk_disable" calls can be moved to the sn9260_init and sn9260_exit functions - thanks to Ryan at Bluewater for this comment.

So audio is now working for me with an 18.432MHz clock also being output on PC1.

Thanks Ryan and Andre,
Ian