[alsa-devel] [PATCH 10/11] ASoC: tegra: Harmony machine support

Mark Brown broonie at opensource.wolfsonmicro.com
Thu Dec 23 03:19:16 CET 2010


On Wed, Dec 22, 2010 at 05:13:20PM -0800, Stephen Warren wrote:
> Mark Brown wrote:

> > The below *completely untested* patch should get the FLL going, though
> > I really must emphasise the *completely untested* part - the patch


> Unfortunately, this doesn't seem to work for me.

Oh dear.  I did say it was completely untested :)

> I briefly investigated, and think the following code is required near the
> end of wm8903_hw_params() right before all the register write calls:

> 	if (wm8903->sysclk_src == WM8903_SYSCLK_FLL)
> 		clock1 |= WM8903_CLK_SRC_SEL_MASK;
> 	else
> 		clock1 &= ~WM8903_CLK_SRC_SEL_MASK;

> (plus some extra defines in the header for that field)

Yes, that's definitely needed at some point - good spot.

> As an aside, I was looking through the Tegra documentation, and in fact
> the cdev1 pin (which feeds the codec MCLK) can be sourced from pll_a,
> i.e. the same clock domain as the I2S bit clock. The existing kernel
> clock driver is simply missing the code to set this up.

OK, that's a better solution anyway as it uses less power - the only
reason to use the FLL if you can provide a good MCLK directly would be
to allow the CODEC to clock itself with the CPU completely off for jack
or button detection but that is fairly unusual (usually jack detection
wouldn't be a wake event).

> Again unfortunately, implementing and doing that doesn't solve the noise
> issue. I suppose I need to start probing the pins with a 'scope/analyzer
> to make sure of what's really coming out of Tegra. Pity they're so small
> and have no test points:-(

Does providing a good MCLK have any impact at all on the noise levels?
It might be interesting to try having the CODEC master the I2S bus - it
might not change anything, but it sometimes shows up if one of the clock
lines is misconfigured.

> P.S. In theory I'm on holiday/vacation until the 2nd. Perhaps I'll get
> bored and keep toying with this though...

Me too.  Once I'm back in the office I can test the code out with real
audio test equipment which might give some hints as to what is wrong
with the setup without having to probe.


More information about the Alsa-devel mailing list