Re: [alsa-devel] [PATCH 10/11] ASoC: tegra: Harmony machine support
Mark Brown wrote:
On Fri, Dec 17, 2010 at 11:06:18PM +0000, Mark Brown wrote:
I'll make sure the FLL is supported as soon as possible, and if we can get these drivers working on Harmoney we could also do the machine driver updates there.
The below *completely untested* patch should get the FLL going, though I really must emphasise the *completely untested* part - the patch needed a bit of rework for 2.6.36 and I spent longer than intended fighting with the Harmony rather than setting up my normal test system as the Harmony setup had looked like it'd work.
Mark,
Unfortunately, this doesn't seem to work for me.
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)
However, with that, all I hear is silence. That's the same thing as happens when MCLK isn't provided at all, so I suppose there's something else missing in the FLL programming too.
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.
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:-(
P.S. In theory I'm on holiday/vacation until the 2nd. Perhaps I'll get bored and keep toying with this though...
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.
Mark Brown wrote:
On Wed, Dec 22, 2010 at 05:13:20PM -0800, Stephen Warren wrote:
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.
Having the codec be master of the bit and frame clocks appears to completely solve the noise issues. I do notice that different sample rates play the same audio at different pitches though, so something is still wrong, but it's most likely to be incorrect codec MCLK input right now; I'll keep investigating...
Thanks.
On Mon, Jan 03, 2011 at 11:39:32AM -0800, Stephen Warren wrote:
Mark Brown wrote:
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.
Having the codec be master of the bit and frame clocks appears to completely solve the noise issues. I do notice that different sample rates play the same audio at different pitches though, so something is still wrong, but it's most likely to be incorrect codec MCLK input right now; I'll keep investigating...
That's progress; with the CODEC as master all the clocks within the CODEC will be configured correctly in relation to one another which will help with the noise - probably the MCLK rate does have issues like you say, with the CODEC as master pitch variations are a likely symptom.
participants (2)
-
Mark Brown -
Stephen Warren