On Fri, Dec 17, 2010 at 02:40:02PM -0800, Stephen Warren wrote:
> Mark Brown wrote:
> > On Fri, Dec 17, 2010 at 02:41:29PM -0700, Stephen Warren wrote:
> > So, I actually have a one of these... If I can figure out how to get a
> > useful kernel onto it I should be able to boot and test it.
> That's be great. I did look at a sine wave on a 'scope, and there's a heck
> of a lot of random or high-frequency noise on it...
See below...
> > > + err = snd_soc_dai_set_sysclk(cpu_dai, 0, bitclock, SND_SOC_CLOCK_IN);
> > > + if (err < 0) {
> > > + pr_err(PREFIX "cpu_dai clock not set\n");
> > > + return err;
> > > + }
> > Ah, this isn't bitclock, it's MCLK for the CODEC...
> Ah. Perhaps that would explain some of the issues.
> The clock fiddling above configures the I2S bit clock. This is fed out the
> DAP1_SCLK pin of Tegra and into the BCLK pin of the codec.
> The I2S driver then divides this down to generate the I2S LR clock.
> We need to pick different frequencies for BCLK, because there's no frequency
> within Tegra's clock limits (for pll_a, the root of the audio clock tree) that
> is a common multiple of the bit clocks for all sample rates from 8000 to
> 96000Hz.
You do need to pick different BCLKs for at least the 44.1k and 48k based
rates but typically BCLK is chosen to be channels*rate*sample size,
giving the minimum possible BCLK rate (and therefore minimum power
consumption from BCLK edges). For 16 bit stereo this comes out as 32fs
which is a bit lower than what you've got, though it could be that the
Tegra requires this to be higher.
> The codec's MCLK pin is driven by Tegra's DAP_MCLK1 pin. That is at a fixed
> 26MHz frequency.
> Should I be passing the 26MHz fixed MCLK not I2S BCLK frequency to
> snd_soc_dai_set_sysclk(codec_dai)?
Yes, you should. But with things as they stand this configuration is
really not going to work well as MCLK needs to be a nice multiple of the
sample rate and should be in the same clock domain also (this is all
true for the overwhelming majority of audio parts). With the current
configuration the CODEC is not going to be performing to spec even at
the higher frequencies, and the greater the divergence between the
configured and actual clocking the worse the performance will be.
Fortunately the WM8903 added an FLL in the silicon revisions that went
to production (which has not been implemented in the driver yet) which
should be able to generate a suitable frequency from the clocks it has -
in this case where the MCLK input is not synchronised to the audio
clocks it'd be best to either make the WM8903 the clock master on the
audio bus and use MCLK as the FLL reference or use the BCLK as the
reference for the FLL, in which case the Tegra configuration can be left
pretty much as-is (though reducing the BCLK and scaling with sample rate
would be a bit neater).
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
