On Tue, Jan 20, 2015 at 08:21:18PM +0800, Zidan Wang wrote:
+static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq)
- if ((tx && sai->synchronous[TX]) || (!tx && !sai->synchronous[RX])) {
regmap_update_bits(sai->regmap, FSL_SAI_RCR2,FSL_SAI_CR2_MSEL_MASK, FSL_SAI_CR2_MSEL(sai->mclk_id));regmap_update_bits(sai->regmap, FSL_SAI_RCR2,FSL_SAI_CR2_DIV_MASK, savediv - 1);
Hmm...the case should be a bit more complicated here IMO.
"tx && sai->synchronous[TX]" means the playback in synchronous mode (TX following RX). What if the recording has been already activated with an MSEL setting at this point? Then the playback stream, as a secondary stream, will overwrite MSEL of the first stream -- Record. Same would happen to the DIV configuration.
@@ -297,6 +368,24 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream, unsigned int channels = params_channels(params); u32 word_width = snd_pcm_format_width(params_format(params)); u32 val_cr4 = 0, val_cr5 = 0;
- int ret;
- if (!sai->is_slave_mode) {
ret = fsl_sai_set_bclk(cpu_dai, tx,2 * word_width * params_rate(params));if (ret)return ret;/* Do not enable the clock if it is already enabled */
It actually doesn't matter to enable the clock again since it purely increaes its count. But we do need a protection for MSEL overwritten issue resulted from the fsl_sai_set_bclk() call.
@@ -133,10 +135,13 @@ struct fsl_sai { struct clk *mclk_clk[FSL_SAI_MCLK_MAX];
bool is_lsb_first;
bool is_slave_mode; bool is_dsp_mode; bool sai_on_imx; bool synchronous[2];
unsigned int mclk_id;
unsigned int mclk_streams;
Besides, I doubt that only one property of mclk_id can content Asynchronous Mode -- TX and RX can fetch their clocks from different MCLK sources.
Nicolin