Mark Brown wrote at Monday, April 18, 2011 8:41 AM:
On Sun, Apr 17, 2011 at 08:45:22AM -0700, Stephen Warren wrote:
Also, I renamed harmony.c to be tegra_wm8903.c since there are a number of boards using Tegra with that codec. I wonder if we'll have the same situation with this codec, such that this new combination should be e.g. SND_SOC_TEGRA_TLV320AIC2x and tegra_tlv320aic2x.c?
I'm not a massive fan of this if people aren't cloning a single reference design - it seems better to factor out the code when we see it's being shared and that there's not lots of side warts that cause hassle.
Refactoring later is fine by me.
// First line cribbed from tlv320aic3x.c. // Yes, that's not the codec here, but the logic applies I think. fsref = (srate % 11025 == 0) ? 44100 : 48000; mclk = 256 * fsref;
That's pretty much illegible due to the ternery operator and...
... although the rate calculations in tlv320aic23.c are more complex, so I could be persuaded otherwise.
...it's for a completely different CODEC with different requirements and features.
Yes, given that, the name "fsref" probably isn't a good idea, since that name is specific to an unrelated codec.
"The logic applies" meant that the calculations yield the results that are desired, rather than implying the internals of the codecs are related.
The tables in that part's datasheet imply MCLK should be either 256*44100 or 256*48000, hence the logic above (well, there are also tables for 384*fs too).
Perhaps those are more examples v.s a set of requirements though. I note that code in the codec driver can handle a much wider variety of MCLK values, with different ratios, than the small set of tables in the datasheet.